Seminario de Sistemas - LU209598 -UNSa
-
Upload
jodelrodrigo -
Category
Documents
-
view
18 -
download
0
description
Transcript of Seminario de Sistemas - LU209598 -UNSa
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 7
Universidad Nacional de Salta
Facultad de Ciencias Exactas
Seminario de Sistemas
Año 2014
Informe Final
“Sistema de emisión de carnet de conducir electrónico”
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 8
Alumno: Joel Rodrigo Escalera Díaz
L.U.:209.598
Directora: Lic. Adriana Binda
Comisión:
Mg. Gustavo Gil
Lic. Loraine Gimson
Lic. Patricia Aballay
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 9
Dedicatoria
Ima Susy
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 10
Agradecimientos
A papá y a Iris quienes me ayudaron durante este ciclo.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 11
Índice General
Introducción 7
Capítulo I Funcionalidades del Sistema – Puntuaciones 9
1 Funciones del Sistema 10
1.1 Controles Médicos 10
1.2 Control Teórico-Práctico 10
1.3 Controles de Antecedentes 11
1.4 Emisión del Carnet de Conducir 11
1.5 Emisión y Reemisión del Carnet de Conducir 12
1.6 Infracciones 13
1.7 Puntos – Perforación 13
1.8 Otros Organismos 15
1.8.1 Compañías de Seguros 15
1.8.2 Ventas de Automóviles – Motocicletas 15
1.8.3 Sistema automático de captura de infracciones 16
1.8.4 Medidas Negativas y Positivas 16
Capítulo II – Objetivos y Funcionalidades 17
1 Objetivo general 18
1.1 Objetivos específicos 18
1.2 Funcionalidades analizadas para el sistema 18
Capítulo III – Herramientas de Desarrollo 19
1 Uso de herramientas en el presente Seminario de Sistemas 20
1.1 Pencil 20
1.2 Visual Studio 2010 21
Capítulo IV - Estudio de Factibilidad 22
1 Inicio de recolección de datos 23
1.1 Datos recolectados 23
1.2 Estudios de factibilidad 28
1.2.1 Factibilidad operacional 28
1.2.2 Factibilidad técnica 28
1.2.3 Factibilidad económica 29
1.2.4 Comparación de los sistemas 33
1.2.4.1 Comparación en la recaudación entre el sistema informático y 33
1.2.4.2 Comparación entre el sistema informático y manual 36
1.2.5 Conclusión 38
1.3 Diagrama de Gantt estimado 38
Capítulo V – Análisis 40
Iteración 1: Lista de los primeros Casos de Uso 41
1 Análisis del sistema Objeto 41
Iteración 2: Refinación de lista de Casos de Uso y desarrollo de cada uno 42
1 Refinación de la lista de Casos de Uso y desarrollo de cada uno 42
1.1 Casos de Uso 42
1.2 Diagramas de Casos de Uso 43
1.3 Casos de Uso: Desarrollo de cada Caso de Uso para la segunda 44
1.4 Diagramas de clases 67
1.5 Primer diseño de interfaz 67
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 12
Iteración 3: Corrección de Caso de Uso – Modelo de clases 69
1 Corrección de Casos de Uso – Modelo de clases 69
1.1 Diagrama de clases 69
1.2 Casos de Uso 70
1.2.1 Casos de Uso resultantes en esta iteración 71
1.3 Conclusión al término de las iteraciones para el diseño 77
Capítulo VI – Diseño 80
Iteración 4: Diagramas de Interacción – Modelo de clases final 81
1 Diagramas 81
1.1 Diagramas de Interacción 81
1.2 Lista de Diagramas de Interacción 81
1.3 Diagramas de Clases 93
Iteración 5: Diagramas de Iteración - Clases 95
1.1 Lista de Diagramas de Interacción 95
1.2 Lista de Pantallas 97
1.3 Diagrama de Clases 100
Iteración 6: Diseño de Interfaz 102
1 Interfaces del Sistema 102
1.1 Diseño de la interfaz 102
1.2 Principios para visualización de la información 102
1.3 Entrada de datos 103
1.4 Diseño Entrada, Salida y Control 103
1.5 PDF147 104
1.6 Diagrama de Clases 105
1.7 Lista de pantallas 106
Capítulo VII – Conclusiones 123
Capítulo VIII - Bibliografía 126
Capitulo IX – Glosario 129
Anexo I – Marco Teórico 131
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 13
Introducción
El sistema objeto a desarrollar, es de emisión de un carnet de conducir electrónico en las diferentes categorías existentes.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 14
Las entidades dedicadas a emitir dicho carnet son generalmente organismos de alcance municipal, de los cuales dependen las ordenanzas que rigen el tránsito y las condiciones para la entrega del mismo.
Se propone el análisis y diseño de un software que maneje una gran cantidad de datos, en una única base de datos, usando para este caso una única legislación federal que regule la emisión del nuevo carnet.
A pesar de que se crearon en nuestro país muy buenos sistemas de control de
tránsito para regular la legislación vial o la emisión de carnet de conducir, no se pudo alcanzar aún un alto nivel de control vial y las diferentes formas de emitir el mismo. En este trabajo se estudiarán las distintas fases del desarrollo del software que funcionará como un conjunto de subsistemas interrelacionados, caracterizado por la complejidad de los datos. Para eso se necesita: modelar la construcción del mismo, observar las interacciones del sistema con el usuario final, refinar los requisitos basados en el sistema manual actual de emisión de carnet de conducir y luego realizar el análisis y el diseño del mismo.
Para esto se aplicará el Proceso Unificado de Desarrollo de Software como metodología, Casos de Usos para identificar las funcionalidades más importantes, Diagrama de Clases para reflejar la estructura del sistema en forma de subsistemas, Clases e Interfaces y Diagramas de Interacción para reflejar a los Casos de Uso como interacciones entre subsistemas, clases e interfaces.
La búsqueda de los casos de uso críticos llevará a conocer de fondo al sistema y que este colabore con el objetivo de la organización. Se espera que el nuevo sistema propuesto minimice la cantidad de trámites burocráticos y se obtengan resultados positivos en un corto plazo.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 15
Capítulo I
Sistema objeto de Estudio
“Emisión de carnet de conducir electrónicos”
Funcionalidades del Sistema
Puntuaciones
1 Funcionalidades del Sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 16
A continuación se describen las principales funciones del sistema.
1.1 Controles Médicos
El control médico constituye uno de los requisitos fundamentales dentro de la
funcionalidad del sistema, pues éste capacita al solicitante a considerarlo apto en el
trámite posterior del carnet de conducir.
Los principales controles a los cuales los usuarios deben someterse son los
siguientes:
Análisis de sangre para determinar el grupo y el factor.
Examen de vista (capacidad de la vista).
Examen psico-físico.
El trámite de emisión se inicia con el consentimiento del futuro usuario, el cual accede al sistema emisor online con su número de DNI, éste autoriza la entrega de los diferentes formularios online enunciado en el párrafo anterior, validos en un período de tiempo determinado. Posteriormente la entrega del carnet se efectúa por correo postal.
Cada centro médico cuenta con acceso al sistema emisor de carnet para obtener los diferentes formularios generados en la solicitud de dicho carnet. El centro médico debe cargar directamente en el sistema, los resultados obtenidos, realizar una impresión y ser firmada por los examinadores como medida de resguardo de datos para el sistema, para ser enviada en un período razonable de tiempo al centro principal de emisión de carnet para ser archivado.
Los centros autorizados deben contar con un plantel de profesionales y declararlo en el sistema para su posterior identificación.
1.2 Control Teórico-Práctico
Quien solicita un carnet de conducir realiza en primera instancia el examen médico y aprobarlo para luego rendir los distintos exámenes previstos; la no aprobación de un examen anula los posteriores trámites y turnos que aquel hubiere solicitado.
Estos exámenes tienen una correlación de ejecución y de aprobación y son los siguientes:
examen medico examen teórico examen practico
El conductor interesado concurre a rendir a los lugares autorizados para la toma de exámenes, una vez concluido este y cualquiera sea el resultado, debe ser cargado en el sistema e incluir: las respuestas efectuadas y la cantidad de intentos hasta haberlo aprobado.
1.3 Controles de Antecedentes
Si se desea tener en un momento dado los antecedentes de un conductor en particular, el principal obstáculo es el acceso a la información, más aún cuando la
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 17
misma no posee un único formato o se encuentra dispersa en diversos municipios donde el conductor haya incurrido en falta o hubiera solicitado con éxito, obtener un carnet de conducir con validez nacional.
El sistema propuesto debe reunir en una única base de datos todos los registros del conductor, que incluye; la solicitud de un carnet de conducir, los distintos exámenes que realice y todas las infracciones en las que hubiere incurrido, de esta manera poder obtener información en tiempo real sin importar el ámbito geográfico en donde se haya registrado.
Estos datos serán de gran utilidad en dicho sistema en el momento de iniciar una solicitud del carnet para poder asignar la categoría correspondiente o decidir la no continuación de la solicitud para el caso en el que conductor se encuentre inhabilitado.
Diversos organismos como las empresas de seguro, las de ventas de automotores, etc. pueden acceder a la información ya existente y de esta manera crear beneficios para el conductor que cumpla las normas viales, tales como un reajuste de la prima a cobrar o un porcentaje de descuento en el caso de ventas de vehículos.
Cada dato en el sistema debe estar acompañado de una identificación del conductor, la fecha, hora y lugar geográfico en que se haya generado el registro.
1.4 Emisión del Carnet de Conducir
El sistema verifica la categoría solicitada, pero tiene en cuenta: los antecedentes del conductor, el resultado de los diferentes exámenes y demás requisitos exigidos.
En el caso de no poder continuar con el trámite gestionado se informa al solicitante los motivos del rechazo para que pueda hacer el descargo correspondiente, y en el caso de continuar, el siguiente paso es la impresión del carnet de conducir.
El carnet de conducir impreso cuenta con un chip para evitar adulteración y duplicado sin autorización y un código de barras, ambos con contenido de información del conductor.
La imprenta debe estar situada en centros de mayor concurrencia poblacional, debido al costo de los equipos, la operabilidad y mantenimiento.
La categoría del carnet hace referencia al tipo de automóvil que el conductor está autorizado, categoría única en el sistema que unifica las categorías existentes y evita así interpretaciones o inconsistencias en todo el territorio nacional.
El color del carnet tiene relación con la solicitud de emisión solicitada por el conductor.
1.5 Emisión y Re-emisión del carnet de Conducir
La primera emisión del carnet solo posee el costo de impresión y de envío a domicilio por correo. Los exámenes teórico-prácticos y médicos son realizados por única vez. Tanto el carnet como los exámenes son realizados por una única vez para cada emisión, y se puede solicitar una nueva re impresión por pérdida o deterioro.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 18
Esta re impresión incluye agregar la leyenda “duplicado”, “triplicado”, etc., en el cuerpo del carnet.
Una segunda emisión, es consecuencia de una solicitud generada para un nuevo carnet de conducir, producida por la pérdida total de los puntos asignados en la primera emisión. Además el conductor debe cumplir con los distintos exámenes realizados en la primera emisión, pero con nivel de exigencia mayor. El costo de la impresión y envío del mismo está a cargo del solicitante además de la multa a pagar por la pérdida de la primera emisión; multa que tiene un monto base.
La tercera solicitud de una emisión es el último escalafón. De la misma manera que en la emisión anterior deberá nuevamente cumplimentar los exámenes previstos con un nivel superior de rigor al nivel precedente.
Después de esta última emisión, no se puede generar una solicitud de re emisión del carnet, salvo en los casos donde la ley incluya el cumplimiento de penalidades u otros casos en donde pueda recuperar puntos, en esta situación el proceso de solicitud es de la tercera emisión a la primera.
Los costos de solicitar un duplicado, triplicados, etc. de un carnet, tiene los mismos que una emisión, siempre que se presente la denuncia sobre el extravío. En el caso de deterioro, el solicitante debe presentar el carnet para su devolución y destrucción.
Las multas por pérdida de la primera o segunda emisión, se calcula dependiendo de parámetros como: los antecedentes, el nivel socio-económico del conductor. El cálculo obtenido no debe ser menor a un monto estipulado por cada emisión.
En ningún caso se puede solicitar una re emisión de un carnet sin antes tener cancelada las multas por infracción.
1.6 Infracciones
El sistema reduce automáticamente los puntos positivos otorgados en un principio de acuerdo a las infracciones vinculadas a un conductor y a la legislación vial vigente.
De acuerdo al tipo de infracción, se procede a reducir puntos de dos maneras:
reducción de puntos reducción de puntos y perforación y perforación.
El carnet de conducir cuenta con cuatro campos para ser perforados de
acuerdo a la magnitud de la infracción cometida. La perforación total, que implica la pérdida total de puntos, sin importar la cantidad que tuviere, significa que el conductor debe realizar nuevamente los trámites de emisión del carnet desde un principio.
El conductor que circule sin carnet de conducir, sin haber aún iniciado la solicitud en el sistema, sufre el descuento máximo de puntos, y será descontado al momento de solicitarla.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 19
El pago de la multa por una infracción dentro del primer plazo impreso tendrá una reducción del monto asignado en un porcentaje previamente tabulado, pero manteniendo el descuento de puntos si correspondiere.
1.7 Puntos – Perforación
Funcionamiento: Puntos de partida:
Mayores de 21 años: 20 Puntos
Mayores de 18 años y menores de 21 años: 16 Puntos, se agrega
automáticamente 4 puntos al cumplir los 21 años.
Algunos casos de recuperación de puntos:
Cursos de sensibilización y reeducación (máximo uno cada dos años): + 2
puntos
Tres años sin haber cometido ninguna infracción: Recuperación de todos
los puntos hasta 12.
Algunas infracciones en las que el sistema debe aplicar la sanción
correspondiente:
6 puntos y perforación del carnet de conducir
Conducir bajo los efectos del alcohol (mayor a 0,75 mg/l. Profesionales, mayor a 0,3
mg/l).
Conducir bajo los efectos de drogas.
Negarse a realizarse las pruebas de alcoholemia o drogas.
4 puntos
Conducir bajo los efectos del alcohol (0,25-0,75 mg/l. Profesionales, 0,15-0,3 mg/l).
Arrojar objetos peligrosos que puedan producir incendios o accidentes.
Conducir de forma negligente o temeraria.
Incumplir la prioridad de paso, incumplir la obligación de detenerse en una señal de
stop tales como paso de peatones y semáforos.
Poner en peligro a los ciclistas.
Adelantos peligrosos (invadiendo el sentido contrario en curvas, lugares con visibilidad
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 20
reducida).
No respetar las señales de los agentes de tránsito que regulan la circulación.
Circular en sentido contrario.
Circular más de un 100% de la velocidad permitida
3 puntos
Circular más de un 50% de la velocidad permitida. No mantener la distancia de
seguridad.
No respetar el cambio de luces a otros usuarios en las rutas durante la noche,
produciendo encandilamiento.
Conducir hablando por el teléfono celular.
Parar o estacionar peligrosamente, por ejemplo en:
o en curvas
o en lugares de visibilidad reducida
o en pasos inferiores
o en pasos nivel
o en lugares peligrosos o en los que se obstaculice gravemente la circulación
2 puntos
Circular más de un 30% de la velocidad permitida
Cambiar de sentido, dirección o dar marcha atrás incumpliendo las normas.
Circular sin usar el encendido de luces cuando sea obligatorio
Conducir sin utilizar el cinturón de seguridad
Circular con menores sin silla reglamentaria para el caso
Conducir sin casco o con casco no homologado
1 punto
El no pago de las multas enviadas a los domicilios en los plazos indicados.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 21
1.8 Otros Organismos
Los otros organismos, se refiere a compañías u otros sistemas que pueden llegar a estar asociados a la persona que conduce un vehículo y que solicita el carnet de conducir.
1.8.1 Compañías de Seguros
El riesgo de incurrir en un accidente de tránsito es mayor en conductores cuya conducta vial esté asociada a un historial de infracciones que aquel que respete las normas viales. Por lo tanto las empresas aseguradoras preferirán contar a estos segundos como principales clientes. Ambos conductores hoy deben pagar la misma prima al momento de contratar una póliza de seguro.
Una compañía de seguro puede acceder a un módulo del sistema que informe el valor de un parámetro, generado por la categoría actual del carnet de conducir y los puntos a favor, que debe ser aplicado en el cálculo de la póliza de seguro y recalcular la prima a cobrar, naturalmente difiere el monto de acuerdo a los antecedentes de un conductor.
1.8.2 Ventas de Automóviles - Motocicletas
De la misma manera que las compañías de seguro pueden recalcular el monto de la prima, la concesionaria encargada de la venta de automóvil o ciclomotor, puede obtener desde el sistema el valor de un parámetro que debe ser aplicado en el precio del vehículo a vender.
En el caso de los ciclomotores, al momento de la venta del vehículo nuevo, se exige la entrega de dos cascos homologados sin cargo.
En ambos casos la venta de un vehículo queda también registrada en un módulo del sistema, y se construye así un historial de vehículos asociados a una persona.
1.8.3 Sistema Automático de captura de infracciones
La instalación de radares y cámaras fotográficas en distintos puntos geográficos, para capturar la imagen de un vehículo en infracción, pone en énfasis la imagen de la patente, para poder así relacionar la infracción con el dueño del vehículo registrado en el sistema.
El sistema, con la captura de la imagen como evidencia de la infracción, inicia el proceso de ejecutar la multa correspondiente, que incluye el descuento de puntos, el cálculo de la multa y el envío del formulario de pago al domicilio del dueño del vehículo en cuestión.
1.8.4 Medidas Negativas y Positivas
En el caso donde el sistema descuenta puntos a los asignados en el carnet de un conductor, es una medida negativa de incentivar a tener una buena conducta.
El conductor que no posea antecedentes por infracciones, se beneficia con descuentos en la prima de un seguro y en la compra de un vehículo. Esto es una medida positiva de incentivar a respetar las normas viales de conducir.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 22
Otra medida positiva, es la funcionalidad del sistema de aumentar automáticamente puntos, como ser:
Que durante un plazo determinado no haya incurrido en infracciones. Que haya participado de grupos creados para la concientización.
Este aumento de puntos no debe ser superior a una cantidad de puntos máximos correspondientes a una emisión y se debe solicitar previamente en el sistema por parte del interesado.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 23
Capítulo II
Objetivos y Funcionalidades
1. Objetivo general
Obtener la especificación de análisis y diseño de la emisión del carnet de
conducir, usando el método de descuento de puntos, aplicando Proceso Unificado.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 24
1.1 Objetivos Específicos
Utilizar la metodología del proceso unificado.
Desarrollar mediante herramientas UML los modelos necesarios.
Proponer una solución informática al problema de emisión y mantenimiento del
carnet de conducir para organismos municipales
1.2 Funcionalidades del sistema
Las funcionalidades a analizar en el sistema son la emisión del carnet de conducir y la re-emisión del mismo dependiendo del antecedente del conductor para poder habilitar un segundo y hasta un tercer ejemplar.
Dichas funciones están agrupadas en los siguientes sub-sistemas:
Disparador de formularios para los distintos controles necesarios en la emisión de los mismos.
Controlador de las multas cargadas al sistema y el envío a los distintos domicilios para el pago de multas anticipadas.
Emisor de las tarjetas magnéticas.
Controlador de los vencimientos de plazos que puedan o no acreditar puntos.
Administrador de usuarios autorizados al sistema.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 25
Capítulo III
Herramientas de Desarrollo
1 Uso de Herramientas en el presente Seminario de Sistemas
1.1 Pencil[SOFTPENCILWWW]: Herramienta para el desarrollo de vista de las pantallas para el
sistema de caso de estudio.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 26
Figura C5.F1: Software - PENCIL (OpenSource)
La misión del proyecto Pencil es construir una herramienta gratuita y de código abierto para hacer diagramas y prototipado GUI que todos puedan usar.
Algunas Funciones Principales:
La exportación a HTML, PNG, documento Openoffice.org, documento de Word
y PDF.
Instalación de plantillas definidas por el usuario y las plantillas.
Adición de objetos externos.
Colección Personal.
Plantilla para la construcción de plantillas de diagramación y creación de
prototipos.
La exportación a HTML, PNG, documento Openoffice.org, documento de Word
y PDF.
Instalación de plantillas definidas por el usuario y las plantillas.
Open Source.
1.2 VisualStudio2010 [SOFTVisualStudio2010WWW]: Herramienta para el desarrollo de los modelos
de casos de usos y caso de uso.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 27
Figura C5.F2: Software - Visual Studio 2010 (Microsoft)
Microsoft Visual Studio es un potente IDE que asegura código de calidad
durante todo el ciclo de vida de toda la aplicación, desde el diseño hasta la
implementación. Si está desarrollando aplicaciones de SharePoint, la web, Windows,
Windows Phone y más allá, Visual Studio es la solución definitiva de all-in-one.
Esta herramienta no es Open Source, por lo que su precio comienza en los
799.00 dólares norteamericanos, pero se usará durante el todo el desarrollo una
versión para estudiantes mediante Msdn Academic Alliance Software Center
(MSDNAA). El software se accede a través de un sitio web dedicado ejecutar ya sea
por correo o por academia de la universidad. El servicio gestionado por e-academy se
llama e-academy License Management System. El acceso está determinado por el
acuerdo de MSDNAA, pero generalmente se administra a los estudiantes que cumplan
con ciertos requisitos.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 28
Capítulo IV
Estudio de Factibilidad
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 29
1. Recolección de datos
El estudio de factibilidad comienza con la recolección de datos e inclusión de
nuevas funcionalidades para luego poder hacer un análisis previo que nos permita
decidir si es viable continuar con el análisis y diseño del sistema.
1.1 Datos recolectados
La Oficina de Automotores de la Municipalidad de Rosario de Lerma, devuelve
con fecha 17 de Octubre, una nota que especifica las condiciones generales la
emisión del carnet de conducir.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 30
Figura C6.F1: Breve Explicación del funcionamiento de la emisión del carnet de conducir por la Municipalidad de Rosario de Lerma
El personal examinador de la policía de tránsito completa el siguiente
formulario, de acuerdo a un previo examen teórico y práctico, en el que se decide si
se deniega o aprueba la condición de considerar al solicitante ser apto y el tipo de
categoría para la confección del carnet de conducir.
Figura C6.F2: Formulario solicitud de realización de prueba de conducir
La figura C6.F3 se corresponde a un folleto en donde se especifican las
distintas señales viales que serán parte del examen escrito.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 31
Figura C6.F3: Folleto Informativo Paginas 1-2
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 32
Figura C6.F4: Folleto Informativo Paginas 3-4
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 33
Figura C6.F5: Folleto Informativo Paginas 5
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 34
1.2 Estudios de Factibilidad
El análisis de factibilidad, se desarrolla durante la fase de inicio del sistema, en general durante la evaluación de las diferentes alternativas de solución propuestas. Los estudios de factibilidad consideran la factibilidad técnica, económica, legal y operacional de cada alternativa, y finaliza con la conclusión para luego decidir si se procede con el estudio, desarrollo o implementación.
1.2.1 Factibilidad operacional
El sistema manual de emisión de carnet de conducir, es muy grande y complejo de mantener debido a la cantidad de información que este contiene, y actualmente el personal está acostumbrado a la manipulación de formularios para todo trámite que se realice y es de esperar que al usar el nuevo sistema informatizado exista un rechazo, aún sabiendo de los beneficios que este sistema proporciona. Por lo tanto, este sistema informatizado debe ser amigable con el usuario y no tener errores no controlados.
Todo personal que trabaja actualmente en el sistema manual, sigue afectado a las mismas funciones que viene realizando, pero con herramientas disponibles para realizar aún mejor sus labores diarias. Debemos tener en cuenta que estas personas tienen experiencia y puede servir para ayudar a una evolución del sistema.
Un reporte solicitado en el sistema manual para un conductor en particular, puede tardar un tiempo considerable de investigación en el archivo como mínimo, y contiene información acotada, pero si el reporte es solicitado por el sistema informático, el tiempo de consulta es casi instantáneo y contiene toda la información disponible en el sistema.
Este sistema, al momento de solicitar la emisión del carnet de conducir, permite sacar turnos para los distintos controles y el resultado de estos ser re-ingresados para la retroalimentación, dando de esta manera agilidad al desarrollo de todos los trámites.
1.2.2 Factibilidad Técnica
El volumen de datos que el sistema controlará al disponer de todos los registros del país, impone la necesidad de contar con una base de datos capaz de administrarlos de forma eficiente, tal como una consulta menor o una consulta suficientemente grande para un reporte en particular.
Actualmente se dispone de software para el desarrollo de este sistema y personal altamente capacitado para llevar a cabo este emprendimiento de gran magnitud. Por lo tanto podremos afirmar que contamos con un equipo de desarrollo capaz de encarar este tipo de proyecto.
Se encuentra a disposición técnica de radares capaces de leer a altas velocidades y de tomar fotografías con alta calidad y las cuales se usan para la captura de infracciones y como evidencia legítima.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 35
La impresión del carnet técnicamente es viable, ya que tiene la misma modalidad de impresión de una cédula federal, incluso la foto y datos legibles por una banda magnética y/o código de barras.
El acceso al sistema por cada conductor o cualquier otro organismo, es mediante una página en Internet, usando protocolos de seguridad, para garantizar la calidad de los datos.
1.2.3 Factibilidad Económica
Los estudios de factibilidad económica incluyen análisis de costos y beneficios asociados con cada alternativa del proyecto.
Los costos del desarrollo y el mantenimiento son muy altos, igualmente se puede afirmar que los beneficios del sistema informatizado son mayores.
Si se compara a mil personas que se dirigen a un centro para la emisión del carnet de conducir, y que todos ellos sacan por el periodo máximo que puede ser 3 años pagando un costo de 55 anual con el 50% de descuento si se hace por 3 años (Precio de la emisión del carnet y el tiempo de vigencia, tomado de la ciudad autónoma de Buenos Aires) tendría un ingreso cada 10 años de $302.500,00. Pero utilizando el sistema propuesto, con un costo de emisión de $50 e incluye la impresión de la tarjeta con fotografía y el envió al domicilio de la persona que tiene validez por 10 años renovables, y que de los $50 solo le puede quedar un 30%, llevando a los números tendríamos $150.000,00, y mirando los números anteriores decimos que el menos del 50% de la recaudación de la primera opción.
Ahora de las 1000 personas tomadas como muestra, supongamos que el 50% es totalmente reincidente y de este grupo el 10% es más aun reincidente y que todos pagarían una multa de $100 anuales, cuando decimos reincidente en nuestro sistema cambiaria rápidamente en menos de un año o dos a otro color y que en 4 años estarían en el ultimo color, y que todos paguen, dejamos al primer 50% como personas con buena conducta y a aquellos que tendrán que desistir totalmente de conducir por los costos que sale renovar nuevamente los carnet de conducir.
Con esto: 500 personas realizan el curso y deben pagar $1.120,00 para poder usar nuevamente el segundo color, se recaudaría un total de $602.500,00 que casi es un 100% más de lo que recauda el otro sistema. Y si agregamos que de este grupo el 10% cae en la tarjeta del tercer color, dijimos que es un 150% mas equivaldría $288.500,00 y sumando in ingresos anteriores, y sumando a los costos de emisión por 800 tarjetas. Se obtendría un total de $1.041.000,00. Que desde el punto económico es altamente aceptable.
Solo falta sumar lo ingresado por multas. Que el sistema manual ingresa $100 pesos anuales, en total de $1.000.000, de los cuales se estima que las infracciones no son todas cobrables o no son detectas es su totalidad.
Con el nuevo sistema, el control es más exhaustivo y puede detectar más de 2 infracciones por año. Lo que ascenderá un 100% la recaudación, de los cuales se cobraría en su totalidad, pero no es un problema del sistema en sí, sino de la entidad que realiza el cobro y que el sistema ayudaría reducir en lo que se refiere a deudores incobrables ya que el sistema no deja emitir una segunda tarjeta de otro color o duplicados si encuentra en su base de datos boletas impagas por el solicitante.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 36
Manejando estos datos, por un periodo de 10 años, con una población de 1000 personas, y si lo consideramos a la cantidad de personas en una provincia entera y descontamos el costo económico operativo y de software resulta óptimamente beneficioso, ya que los centros emisores de tarjetas no estarán emitiendo día y noche durante los 10 años, y los aparatos complejos y caros son pagados con multas que puede captar en pocas semanas.
El personal actual no se reduciría en número, ya que se considera a los mismos como capacitados para llevar a cabo dichas actividades y a manejar gran volumen de datos manuales.
Los costos de capacitación son fijos y no representan un costo excesivo dado a la magnitud de personas que solicitan el carnet de conducir.
En Resumen:
Sistema Actual: Precios y descuentos tomados de la ciudad Autónoma de Buenos Aires.
Personas en Estudio: 1000
Descuento por 3 años 50%
Costo de Carnet por Año $55
Tiempo estimado de estudio 10 años
Cálculo por 10 años
3 años con descuento $82,50
3 años con descuento $82,50
3 años con descuento $82,50
1 año sin descuento $55,00
Sub total 1 Persona $302,50
Total por 1000 Personas $302.500,00
Tabla C6.T1: Resultado del sistema actual, tomando como estudio 10 años sin tener en cuenta los pagos de multas que puede tener esta persona.
Personas de Estudio 1000
Sin descuentos 0%
Costo de Carnet por Año $50
Costo de emisión + envío $35
Tiempo de Estudio 10 años
Cálculo por 10 años
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 37
10 años sin descuento $500,00
Emisión y envío ($350,00)
Sub total 1 Persona $150,00
Total por 1000 Personas $150.000,00
Tabla C6.T2: Resultados con el sistema informático en la solicitud de carnet de conducir por primera vez, a los cuales no le sumamos los pagos por multas y están expresados en Pesos Argentinos.
Personas de Estudio 1000
Personas en 2º Carnet 500
Costo Carnet nuevamente $50
Costo de emisión + envío $35
Costo 2º Color $1120
Cálculo por 10 años
Costo Carnet $50,00
Emisión y envío $35,00
2º Color $1.120,00
Sub total 1 Persona $1.205,00
Total por 500 Personas $602.500,00
Tabla C6.T3: Resultados con el Sistema Informático en el segundo intento de solicitud de la carnet de conducir. Reducida s 500 personas.
Personas de Estudio 1000
Personas en 3º Carnet 100
Costo Carnet nuevamente $50
Costo de emisión + envío $35
Costo 3º Color $2800
Cálculo por 10 años
Costo Carnet $50,00
Emisión y envío $35,00
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 38
3º Color $2.800,00
Sub total 1 Persona $2.885,00
Total por 100 Personas $288.500,00
Tabla C6.T4: Resultado con el Sistema Informático en el tercer intento de solicitud de la carnet de conducir. Reducidas a 100 personas.
Recaudación Sistema Informático
1º Color $150.000,00
2º Color $602.500,00
3º Color $288.500,00
Total $1.041.000,00
Tabla C6.T5: Recaudación total con el Sistema Informático estimado en 10 años.
Los datos son estimativos y pueden variar en el transcurso de 10 años, pero la estimación de la recaudación no va a producirá perdidas, sabiendo que los municipios tienen este tipo de ingreso. Pero la finalidad de usar el sistema, además de brindar una gestión ágil en los trámites, se buscará profundizar en la concienciación de toda persona que circula por la vía pública.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 39
1.2.4 Comparando los dos sistemas:
1.2.4.1 Comparación en la recaudación entre sistema informático y manual
Sistemas Emisores Sistema Manual Recaudación Sistema Informático Recaudación
Inicio $0 0
1º Solicitud $82.500 $82.500 $150.000 $150.000
2º Solicitud $82.500 $165.000 $602.500 $752.500
3º Solicitud $82.500 $247.500 $288.500 $1.041.000
4º Solicitud $55.000 $302.500 $0 $1.041.000
Tabla C6.T6: Comparación de la recaudación al solicitar el carnet de conducir por un período de 10 años.
Figura C6.F6: Sistemas Emisores. Representación gráfica de las comparaciones de los dos sistemas
1º Solicitud
2º Solicitud
3º Solicitud
4º Solicitud
0
200000
400000
600000
800000
1000000
1200000
Sistemas Emisores
Sistema Manual Sistema Informático
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 40
Multas en el sistema Manual
Personas 1000
Multas por año encontradas 1
Multa Modelo $100
Cobrable 100%
Tiempo de Estudio 10 años
Multas por año $100,00
Multas por 10 años $1.000,00
Multas de 1000 personas en 10 años $1.000.000,00
Tabla C6.T7: Multas estimadas cobrables al 100% aproximadamente, al momento de la compra-venta del vehículo.
Multas en el Sistema Informático
Personas 1000
Multas por año encontradas 2
Multa Modelo $100
Cobrable 100%
Tiempo de Estudio 10 años
Multas por año $200,00
Multas por 10 años $2.000,00
Multas de 1000 personas en 10 años $2.000.000,00
Tabla C6.T8: Multas detectadas por el sistema. Se incremente en un 100% las multas encontradas, pero se supone que habrá mas respeto de las normas viales, por lo que solo se incrementa en un 100% como promedio en los 10 años.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 41
Comparado los dos sistemas nuevamente, comparando un porcentaje de cobro positivo:
Tabla C6.T9: Comparación de la recaudación al momento del cobro de las multas aproximado, por un período de 10 años.
Figura C6.F7: Representación gráfica del cuadro anterior, por un período de 10 años.
01
23
45
67
89 10
0
500000
1000000
1500000
2000000
2500000
Sistema Manual Sistema Informático
Sistema Manual Sistema Informático
Años
Precio /
Multa
Infracciones /
Persona
Cobrado
80%
1.000
Personas
Infracciones /
Persona
Cobrado
99% 1.000 Personas
0 $100 1 $80 $80.000 2 $198 $198.000
1 $100 1 $80 $160.000 2 $198 $396.000
2 $100 1 $80 $240.000 2 $198 $594.000
3 $100 1 $80 $320.000 2 $198 $792.000
4 $100 1 $80 $400.000 2 $198 $990.000
5 $100 1 $80 $480.000 2 $198 $1.188.000
6 $100 1 $80 $560.000 2 $198 $1.386.000
7 $100 1 $80 $640.000 2 $198 $1.584.000
8 $100 1 $80 $720.000 2 $198 $1.782.000
9 $100 1 $80 $800.000 2 $198 $1.980.000
10 $100 1 $80 $880.000 2 $198 $2.178.000
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 42
1.2.4.2 Comparación en el entre sistema informático y manual
La información en los dos sistemas:
SISTEMA INFORMATIZADO SISTEMA MANUAL Inviolabilidad
La información no puede ser adulterada, cada acción que realice el usuario será necesario previamente identificarse, la inclusión de hora y fecha para cada acción realizada y técnicas de Back up adecuadas.
La información puede llegar a rehacerse total o parcialmente sin poder comprobarlo.
Secuencialidad
Garantizada por mecanismos de campos auto numéricos e inserción de hora y fecha automática.
Es difícil si la información no está previamente foliada, normalmente las evoluciones de los trámites de una persona son consecutivas sobre un mismo papel.
Reserva de la información privada del conductor
Garantizada por mecanismos de seguridad informáticos.
Garantizada por mecanismos de control al acceso del archivo físico.
Accesibilidad
Utilizable en todo momento o lugar vía internet.
Utilizable en un solo lugar.
Disponibilidad
Siempre disponible para cuando se necesite. Todos los usuarios que estén habilitados pueden acceder a toda la información que se requiera así como para la auditoria, estadísticas, etc.
Dependiendo de la accesibilidad a los archivos físicos.
Riesgo de pérdida de información
Seguridad garantizada con una correcta política de resguardo de la información (back-up)
Frecuentemente expuesta a perdida de los archivos físicos, por su desgaste en el tiempo o por accidente.
Durabilidad
Permanece inalterable en el tiempo para que su información pueda ser consultada
Sufre deterioro con el tiempo o por su propio uso.
Legalidad y valor probatorio
Garantizado por la secuencialidad, la inserción de fecha/hora y el usuario que modifica.
Garantizado sí está bien confeccionada, clara, foliada y completa
Identificación del personal al acceso y manipulación de datos
Cada persona tiene acceso a través de un usuario, permitiendo que el sistema guarde cada acción que este realice.
Solo se puede identificar acciones en formularios donde el personal firme y selle.
Conocimiento del tiempo preciso de un trámite realizado
Garantizada con la inserción de la fecha y hora del servidor principal automáticamente en cada acción.
A veces con fecha y hora
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 43
Redundancia
Organizada y disponible para reusar la información en otros formularios que necesite ser reusada.
Incompleta con información duplicada e innecesaria.
Errores de los datos
Menor número de errores A veces inexacta Estandarización de datos
Único ingreso estandarizado de datos para todos los usuarios del sistema.
Estandarizada según cada organismo municipal que este encargado del manejo de este tipo de datos
Costos de personal administrativo
Puede ser manipulada por los mismos usuarios que requieran de la información.
Requiere personal para el mantenimiento del archivo, (repartir, buscar y ordenar el historial de cada conductor)
Costos de imprenta
No requiere Es necesario para los distintos formularios que la que el organismo municipal necesite.
Costos de papel
Bajo, sólo cuando necesariamente se requiera imprimirla
Alto
Tiempo de Consulta
Más corto Más largo Recordatorios y alertas
De fácil implementación De difícil implementación Disponibilidad de los datos para estadísticas
Inmediata Mediante procesos muy tediosos, costosos y lentos
Búsqueda de información y el cruce de datos con otros organismos
Confiable y procesos con corto tiempo de duración
Dificultosa, poco confiable, costosa y procesos con mayor tiempo de duración
Figura C6.T10: Comparación de dos sistemas de acuerdo a distintos criterios.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 44
1.2.5 Conclusión
De esta forma se concluye que el sistema informático es muy conveniente por la magnitud de ingresos que genera la emisión del carnet de conducir comparado con el sistema manual. Un sistema manual no tiene costo de mantenimiento más que el costo operativo, pero sin tener en cuenta el deterioro de las fichas por la manipulación.
En el caso de usar el sistema informatizado, el costo de construcción y de mantenimiento es largamente superior a los costos de operabilidad de un sistema manual, pero se observan beneficios en la comparación de los dos sistemas tales como el acceso a la información, la generación de estadísticas, la durabilidad de los datos, etc.
1.3 Diagrama de Gantt estimado
El tiempo estimado es de 130 días sin contar los días no laborables como
sábados, domingo ni feriados. Previsto para la realización a partir del martes 1 de julio
hasta el 30 de Diciembre. La documentación se realiza durante el desarrollo del mismo
en las distintas tareas.
Figura C6.F8: El calendario de tareas identifica y visualiza la construcción de los diferentes modelos a lo largo de 5 meses, expresando la duración de cada tarea en semanas.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 45
Tabla C6.T10: El grafico muestra la duración en días y las fechas estimadas de inicio y fin de las mismas.
Los entregables se generarán a medida que avance el desarrollo generalmente estarán expresados en documentos (con excepción de los prototipos ejecutables) guiados por las fases de desarrollo y los flujos de trabajo que incluirán los siguientes modelos:
Modelos Diagramas
Modelo del Dominio 1. Diagramas de Clases (inicial)
Modelo de Casos de Uso 2. Diagramas de Casos de Uso (inicial)
Modelo de Análisis 3. Diagramas de Clases/Objetos (medio)
4. Diagramas de Interacciones (inicial)
Modelo de Diseño
5. Diagramas de Clases (final)
6. Diagramas de Interacciones (final)
7. Modelos de Interfaces (final)
Tabla C6.T11: Lista de Modelos y Diagramas relacionados.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 46
Capítulo V
Análisis
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 47
Iteración 1: Lista de los primeros Casos de Uso
1.1 Análisis del sistema objeto
El sistema funciona siguiendo un contrato entre el personal involucrado, donde
los casos de usos detallan la parte de comportamiento de contrato (…). El caso de
uso, como contrato de comportamiento, captura todo y solo el comportamiento
relacionado con la satisfacción de los intereses del personal involucrado. [Cockburn-AW2001]
La siguiente lista muestra funciones que se espera del sistema, se espera que
sea la primera lista de casos de uso que se va a analizar de ahora en adelante.
Lista de interacciones usuario sistema (1º Iteración)
Nº Caso de Uso
01 Ingresar solicitud online de solicitud del carnet de conducir.
02 Cargar fotografía y firma en el sistema
03 Generar examen teórico
04 Generar examen práctico.
05 Generar examen médico.
06 Actualizar examen teórico
07 Actualizar examen Práctico
08 Actualizar examen Médico
09 Registrar mala conducta de conducir
10 Registrar denuncia.
11 Registrar puntos a evaluar en examen
12 Generar examen automáticamente.
13 Generar ticket a cobrar
14 Administrar nuevo centro de control
Tabla C7.T1: Primera lista de posibles casos de uso, sin refinar.
Esta es una iteración muy corta, solo consta de la primera lista de casos de
uso. En las próximas iteraciones se hará un refinamiento mayor y posterior desarrollo
de cada uno de ellos.
Terminada la primera iteración, se avanzó únicamente en el diagrama de
Casos de Uso.
Diagrama de Casos de Uso
Diagrama del Clases
Diagrama de Iteraciones
Diagrama de Diseño
Análisis
Iteración 1
Iteración 2
Iteración 3
Iteración 4
Diseño Iteración 5
Iteración 6
Tabla C7.T2: Tabla de Diagramas en esta iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 48
Iteración 2: Refinación de lista de Casos de Usos y desarrollo de cada uno
1. Refinación de lista de Casos de Usos y desarrollo de cada uno
1.1 Casos de Uso
Se revisa nuevamente la lista de funciones que se pretende que terminen en
casos de uso y se desarrolla las que nos parecen relevantes. Se encuentran nuevas
funciones, que se añaden a la lista. Algunas de estas se depurarán y no se
desarrollarán por no estar dentro de los casos de estudio del sistema.
Nº Funciones que esperamos de la interacción Usuario–Sistema.
1 El solicitante ingresa solicitud online del carnet de conducir
2 El sistema genera test de examen teórico para el solicitante
3 El sistema genera test de examen práctico para el solicitante
4 El sistema genera test de examen médico para el solicitante
5 El sistema genera tickets de pagos
6 El solicitante realiza examen
7 El examinador carga resultado test practico en el sistema
8 El examinador médico carga resultado de estudios en el sistema
9 El solicitante ingresa fotografía en el sistema
10 El solicitante ingresa firma en el sistema
11 El usuario ingresa cuestionario en el sistema
12 El usuario ingresa pago de ticket en el sistema
13 El usuario ingresa reglamento de puntos al sistema
14 El usuario ingresa reglamento de condiciones de solicitud de carnet de conducir al
sistema
15 El usuario ingresa reglamento de multas a aplicar en el sistema
16 El administrador ingresa centro de examen médico en el sistema
17 El administrador ingresa médicos en el sistema
18 El administrador ingresa examinador en el sistema
19 El solicitante consulta estado de solicitud iniciada
20 El administrador ingresa condiciones de recupero de puntos
21 El administrador ingresa condiciones de recupero de niveles del carnet de conducir.
22 Agente ingresa nueva infracción en el sistema
23 El solicitante ingresa solicitud de recupero de puntos
24 El solicitante ingresa solicitud de recupero de nivel del carnet de conducir.
25 El Solicitante se inscribe en el sistema.
26 Centro médico actualiza turnos en el sistema
Tabla C8.T1: Lista de Casos de Usos Refinados listo para desarrollar
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 49
Algunos casos de uso que no se incluye en el análisis son aquellos casos de uso
que sean de mantenimiento llamados ABM (alta, baja y modificación). Algunos de ellos
se conocen a partir de la lista anterior, y se detallan algunas a continuación:
A) ABM de categorías de carnet de conducir.
B) ABM de Médicos autorizados
C) ABM de Centros de impresión de carnet de conducir.
D) ABM de Centros de gestión de carnet de conducir.
Una vez que se hayan detectado los casos de uso en una primera iteración, es
necesario preguntarse: ¿Son estos casos de uso suficientes para analizar y continuar?
¿Son realmente todos casos de uso a considerar?
Luego de revisar la lista final de actividades, que resultó de una nueva revisión,
ahora se pretende refinar aún más y sacar a aquellas que no cumple con la definición
del proceso del negocio elemental.
La primera conclusión observable: se encuentra a varios de ellos con el típico
comportamiento de administración, tal es el caso de la función número 11 “Ingreso de
cuestionario en el sistema” (alta, baja y modificación) o también es el caso de la
función número 20 “El solicitante consulta estado de solicitud iniciada” el cual no
cumpliría con la definición del proceso del negocio elemental, por no dejar los datos
en un estado consistente y es retirada de la lista.
En una nueva refinación o revisión de la lista, se considera que cada acción que
realice el usuario en el sistema, debe quedar registrado o sea que el sistema tendrá el
usuario y la fecha de modificación realizada, por lo tanto se deja a los datos en un
estado consistente y a consecuencia de esta decisión, las funciones número 11 y 20
son nuevamente incluidos en la lista.
Una vez definida la lista con la cual se va a trabajar, se crea el diagrama de
casos de uso.
1.2 Diagrama de Casos de Uso
Como sugiere Larman los actores principales a la izquierda, y los actores de
apoyo a la derecha, se usa también otro diagrama para mostrar a los actores
informáticos, tales como el procesamiento de los pagos que se hagan ya sea por una
multa a pagar o por cualquier ticket que emita el sistema y se deba realizar el pago del
mismo.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 50
Figura C8.F1: Diagrama de Casos de Uso
Los casos de uso se hacen de acuerdo a la lista de funciones que se creó
anteriormente y se avanza estudiando cada uno de ellos y desarrollando en forma
exhaustiva y para una mejor comprensión.
1.3 CASOS DE USO: Desarrollo de cada Caso de Uso para la segunda
iteración
CU: 01 Ingresar solicitud online del carnet de conducir
Actor: Conductor
Evento Inicial: Se solicita inicio de trámites en el Sistema
Precondiciones: Usuario autenticado en el sistema
Post condiciones: Primera etapa del trámite terminado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Opción generación de carnet de
conducir
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 51
02 Dar bienvenida al inicio del trámite online
03 Desplegar diferentes categorías y el tipo de carnet
correspondiente a la categoría del Usuario (por
colores)
04 Elegir una categoría
05 Detallar lista de tipos de exámenes disponibles
06 Elegir un tipo de examen
07 Detallar Instituciones disponibles de acuerdo al tipo
de examen seleccionado
08 Elegir una Institución
09 Detallar calendario con fechas y horario de la
institución seleccionada
10 Elegir fecha y horario
11 Mostrar pantallas con las opciones elegidas.
12 Repetir los pasos 07-11 hasta elegir finalmente la institución, fecha y la hora correcta correspondiente a un tipo
de examen seleccionado
13 Repetir los pasos 06-11 hasta elegir los tipos de exámenes a inscribirse
14 Registrar datos seleccionados e ingresados previa
validación.
15 Generar transacciones por cada una de las
opciones elegidas
16 «include» Incluye Caso de Uso 05 “Generar ticket
de pago”
17 Repetir el paso 17 hasta haber generado todos los tickets de pago por todas las opciones elegidas.
18 Mostrar los tickets a pagar correspondientes a las
opciones elegidas.
19 Imprimir tickets.
20 Emitir mensaje de éxito de la operación.
Caso de Excepción
14 Registrar datos seleccionados e ingresados previa validación.
14.1 Informar ítems vacíos o ingresados pero no
válidos
14.2 Volver al paso 12
Figura C8.F2: Casos de Uso: Ingresar solicitud online de solicitud de carnet de conducir
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 52
CU: 02 Generar Test de Examen Teórico para el Solicitante.
Actor: Conductor
Evento Inicial: Se actualiza los datos del Solicitante, después que elija la categoría.
Precondiciones: Usuario autenticado en el sistema
Post condiciones Examen Teórico Terminado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Inicio de generación de examen
teórico.
02 Verificar identidad y categoría del solicitante
03 Mostrar Inicio de generación de examen
04 Iniciar generación de Examen Teórico
05 Asociar preguntas de Examen Teórico a realizar a la
solicitud
06 Mostrar leyenda examen teórico generado.
07 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Verificar identidad y categoría del solicitante (si bien el usuario está validado, cada acción debe tener
nuevamente una validación interna)
02.1 Volver a la página de logeo
02.2 Cerrar Caso de Uso
Figura C8.F3: Casos de Uso: Generar Test de Examen Teórico para el Solicitante.
CU: 03 Generar Test de Examen Práctico para el Solicitante.
Actor: Conductor
Evento Inicial: Se actualiza los datos del Solicitante, después que elija la categoría.
Precondiciones: Usuario autenticado en el sistema
Post condiciones: Examen Practico Terminado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Inicio de generación de examen
teórico.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 53
02 Verificar identidad y categoría del solicitante
03 Mostrar Inicio de generación de examen
04 Iniciar generación de Examen Practico
05 Asociar preguntas de Examen Practico a realizar a
la solicitud
06 Mostrar leyenda examen teórico generado.
07 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Verificar identidad y categoría del solicitante (si bien el usuario está validado, cada acción debe tener
nuevamente una validación interna)
02.1 Volver a la página de logeo
02.2 Cerrar Caso de Uso
Figura C8.F4: Casos de Uso: Generar Test de Examen Práctico para el Solicitante.
CU: 04 Generar Test de Examen Médico para el Solicitante.
Actor: Conductor
Evento Inicial: Se actualiza los datos del Solicitante, después que elija la categoría.
Precondiciones: Usuario autenticado en el sistema
Post condiciones:
Examen Médico Terminado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Inicio de generación de examen
teórico.
02 Verificar identidad y categoría del solicitante
03 Mostrar Inicio de generación de examen
04 Iniciar generación de Examen Médico
05 Asociar preguntas de Examen Médico a realizar a la
solicitud
06 Mostrar leyenda examen teórico generado.
07 Emitir mensaje de éxito de la operación.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 54
Caso de Excepción
02 Verificar identidad y categoría del solicitante (si bien el usuario está validado, cada acción debe tener
nuevamente una validación interna)
02.1 Volver a la página de logeo
02.2 Cerrar Caso de Uso
Figura C8.F5: Casos de Uso: Generar Test de Examen Médico para el Solicitante.
CU: 05 Generar tickets de pagos
Actor: Conductor
Evento Inicial: Se actualiza los datos del Solicitante, categoría y tipo de transacción a cobrar.
Precondiciones: Usuario autenticado en el sistema
Post condiciones: Ticket a Pagar Calculado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Iniciar generación de tickets a pagar
02 Verificar identidad y categoría del solicitante
03 Mostrar Inicio de generación de tickets
04 Generar transacción
05 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Verificar identidad y categoría del solicitante (si bien el usuario está validado, cada acción debe tener
nuevamente una validación interna)
02.1 Volver a la página de logeo
02.2 Cerrar Caso de Uso
Figura C8.F6: Generar tickets de pagos
CU: 06 Realizar examen teórico
Actor: Examinador Teórico, Conductor.
Evento Inicial:
Precondiciones: Usuario registrado, solicitud inicializada
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 55
Post condiciones: Examen Teórico realizado.
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Ingresar DNI del Conductor
02 Validar DNI del Conductor
03 Seleccionar opción EXAMEN TEORICO
04 Mostrar duración máxima de examen
05 Mostrar cantidad de preguntas a realizar
06 Inicializar examen
07 Registrar Fecha y hora de inicio de examen.
08 Mostrar pregunta
09 Mostrar posibles respuestas
10 Elegir la respuesta eligiendo las opciones
mostradas.
11 Repetir los pasos 8-10 hasta terminar todas las preguntas
12 Dar por terminado el examen
13 Validar respuestas ingresadas
14 Registrar Fecha y hora final de examen.
15 Mostrar resultados
16 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
13 Validar respuestas ingresadas
13.1 Informar ítems vacíos o ingresados pero no
válidos
13.2 Volver al paso 08
Figura C8.F8: Cargar resultado examen de practicas
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 56
CU: 07 Cargar resultado examen de practicas
Actor: Examinador Práctico.
Evento Inicial:
Precondiciones: Examen ya cargado, Usuario registrado, solicitud inicializada
Post condiciones: Examen Teórico realizado.
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Ingresar DNI del Conductor
02 Validar DNI del Conductor
03 Seleccionar opción Examen Practico
04 Mostrar duración máxima de examen
05 Mostrar cantidad de puntos a evaluar
06 Inicializar examen
07 Mostrar Fecha y hora de inicio de examen.
08 Mostrar un punto a evaluar
09 Mostrar posibles respuestas
10 Elegir la respuesta eligiendo las opciones
mostradas.
11 Repetir los pasos 8-10 hasta terminar todos los puntos a evaluar
12 Dar por terminado el examen
13 Validar respuestas ingresadas
14 Mostrar Fecha y hora final de examen.
15 Mostrar resultados
16 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
13 Validar respuestas ingresadas
13.1 Informar ítems vacíos o ingresados pero no
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 57
válidos
13.2 Volver al paso 08
Figura C8.F8: Cargar resultado examen de practicas
CU:
08 Cargar resultado examen médico-clínico
Actor: Examinador Médico
Evento Inicial:
Precondiciones: Examen ya cargado, Usuario registrado, solicitud inicializada
Post condiciones: Examen Teórico realizado.
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Ingresar DNI del Conductor
02 Validar DNI del Conductor
03 Mostrar opción Examen Médico-Clínico.
04 Mostrar duración máxima de examen
05 Mostrar cantidad de puntos a evaluar
06 Inicializar examen
07 Mostrar Fecha y hora de inicio de examen.
08 Mostrar un punto a evaluar
09 Mostrar posibles respuestas
10 Elegir la respuesta eligiendo las opciones
mostradas.
11 Repetir los pasos 8-10 hasta terminar todos los puntos a evaluar
12 Dar por terminado el examen
13 Validar respuestas ingresadas
14 Mostrar Fecha y hora final de examen.
15 Mostrar resultados
16 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 58
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
13 Validar respuestas ingresadas
13.1 Informar ítems vacíos o ingresados pero no
válidos
13.2 Volver al paso 08
Figura C8.F9: Caso de Uso: Cargar resultado examen médico-clínico
CU: 09 Cargar fotografía en el sistema
Actor: Conductor
Evento Inicial:
Precondiciones: Usuario registrado, solicitud inicializada
Post condiciones: Fotografía cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Ingresar DNI del Conductor
02 Validar DNI del Conductor
03 Mostrar opción carga de fotografía
04 Mostrar inicio de captura de fotografía
05 Cargar Imagen temporalmente
06 Mostrar foto cargada
07 Repetir los pasos 04-06 hasta determinar la foto a usar
08 Guardar fotografía elegida
09 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Figura C8.F10: Caso de Uso: Cargar fotografía en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 59
CU: 10 Cargar huella digital en el sistema
Actor: Conductor
Evento Inicial:
Precondiciones: Usuario registrado, solicitud inicializada
Post condiciones: Huella y firma digital cargada en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Ingresar DNI del Conductor
02 Validar DNI del Conductor
03 Mostrar opción carga de huella digital
04 Mostrar inicio de captura de huella digital
05 Cargar Huella dactilar temporalmente
06 Mostrar huella digital cargada
07 Validar huella Digital capturada
08 Repetir los pasos 04-07 hasta determinar la huella digital a Guardar
09 Guardar Huella Digital
10 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
07 Validar huella Digital capturada
07.1 Informar huella digital no válida
07.2 Volver al paso 04
Figura C8.F11: Caso de Uso: Cargar huella digital en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 60
CU: 11 Ingresar cuestionario en el sistema
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema, Categorías cargadas en el sistema
Post condiciones: Cuestionario cargado para los exámenes
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Ingreso de cuestionario en el
sistema
02 Mostrar tipos de Exámenes
03 Elegir un tipo de Examen
04 Mostrar Categorías
05 Elegir una Categoría
06 Mostrar pantalla de Cuestionario a cargar
07 Cargar cuestionario
08 Mostrar Cuestionario cargado
09 Mostrar pantalla de carga de posibles
respuestas al cuestionario anteriormente
cargado
10 Cargar posibles respuestas
11 Validar cuestionario completado
12 Guardar cuestionario
13 Validar posibles respuestas completadas
14 Guardar posibles respuestas
15 Repetir los pasos 06-14 hasta cargar todos los cuestionario correspondientes a la categoría y tipo de
examen
16 Repetir pasos 04-14 hasta guardar los cuestionarios correspondientes a una categoría
17 Repetir pasos 02-14 hasta guardar los cuestionarios correspondientes a un tipo de examen
18 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 61
Caso de Excepción
11 Validar cuestionario completado
11.1 Informar ítems vacíos o ingresados pero no
válidos
11.2 Volver al paso 06
Caso de Excepción
13 Validar posibles respuestas completadas
13.1 Informar ítems vacíos o ingresados pero no
válidos
13.2 Volver al paso 09
Figura C8.F12: Caso de Uso: Ingresar cuestionario en el sistema
CU: 12 El usuario ingresa pago de ticket en el sistema
Actor: Banco
Evento Inicial:
Precondiciones: Logeado en Sistema, Tickets generados para hacer pagos
Post condiciones: Tickets cancelados
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Ingreso de pagos efectuados en el
sistema
02 Mostrar pantalla de ingreso de códigos de
pagos
03 Ingresar Código de pagos
04 Mostrar Código ingresado
05 Validar Código ingresado
06 Guardar Código ingresado
07 Realizar los pasos 02-06 hasta terminar de cargar los pagos
08 Emitir mensaje de éxito de la operación.
Caso de Excepción
05 Validar Código ingresado
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 62
02.1 Informar Código ingresado no válido
02.2 Volver al paso 02
Figura C8.F13: Caso de Uso: Ingresar pagos efectuados en el sistema
CU: 13 Ingresar reglamento de los puntos en el sistema
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Reglamento cargado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar reglamento de los puntos en el
sistema
02 Mostrar pantalla de ingreso de reglamentos
de puntos
03 Ingresar nuevo reglamento
04 Mostrar Código del reglamento
05 Ingresar descripción del punto
06 Ingresar puntos
07 Validar nuevo reglamento
08 Guardar nuevo reglamento
09 Realizar los pasos 02-08 hasta terminar de cargar los reglamentos
10 Emitir mensaje de éxito de la operación.
Caso de Excepción
07 Validar nuevo reglamento
07.1 Informar ítems vacíos o ingresados pero no
válidos
07.2 Volver al paso 02
Figura C8.F14: Caso de Uso: Ingresar reglamento de los puntos en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 63
CU: 14 Ingresar reglamento de las condiciones para la solicitud de carnet de conducir en el
sistema
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Reglamento para condiciones de solicitud cargado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar reglamento de las condiciones para
la solicitud de carnet de conducir en el sistema
02 Mostrar pantalla de ingreso de reglamentos
de condiciones para solicitud de carnet de
conducir
03 Ingresar nueva condición al reglamento
04 Mostrar Código de la condición del
reglamento
05 Ingresar categoría de la nueva condición
06 Ingresar descripción del reglamento
07 Ingresar puntos de la condición
08 Validar reglamento ingresado
09 Guardar reglamento
10 Realizar los pasos 03-09 hasta terminar de cargar los reglamentos
11 Emitir mensaje de éxito de la operación.
Caso de Excepción
08 Validar reglamento ingresado
08.1 Informar ítems vacios o ingresados pero no
válidos
08.2 Volver al paso 02
Figura C8.F15: Caso de Uso: Ingresar reglamento de las condiciones para la solicitud de carnet de conducir s en el sistema
CU: 15 Ingresar reglamento de las multas a aplicar en el sistema
Actor: Administrador
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 64
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Reglamento para las multas cargado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de reglamento de las multas
a aplicar.
02 Mostrar pantalla de ingreso de multas
03 Ingresar nueva multa
04 Mostrar Código de la multa
05 Ingresar categoría de la multa
06 Ingresar descripción de la multa
07 Ingresar puntos de la multa
08 Ingresar Monto de la multa
09 Validar reglamento ingresado
10 Guardar reglamento
11 Realizar los pasos 03-09 hasta terminar de cargar los reglamentos
12 Emitir mensaje de éxito de la operación.
Caso de Excepción
09 Validar reglamento ingresado
09.1 Informar ítems vacíos o ingresados pero no
válidos
09.2 Volver al paso 02
Figura C8.F16: Caso de Uso: Ingresar reglamento de las multas a aplicar en el sistema
CU: 16 Ingresar centros médicos en el sistema
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Centros Médicos cargado en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 65
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Ingreso de centros médicos en el
sistema
02 Mostrar pantalla de ingreso de centro
médicos
03 Ingresar nuevo céntrico medico
04 Mostrar Código del centro medico
05 Ingresar Nombre del Centro medico
06 Ingresar Domicilio del centro medico
07 Ingresar Teléfono del centro médico.
08 Ingresar contacto del centro médico.
09 Validar centro médico ingresado
10 Guardar Centro médico
11 Realizar los pasos 03-079hasta terminar de cargar los pagos
12 Emitir mensaje de éxito de la operación.
Caso de Excepción
09 Validar centro médico ingresado
09.1 Informar ítems vacíos o ingresados pero no
válidos
09.2 Volver al paso 02
Figura C8.F17: Caso de Uso: Ingresar centros médicos en el sistema
CU: 17 Ingresar médicos en el sistema
Actor: Administrador
Evento Inicial:
Precondiciones Logeado en Sistema
Post condiciones: Médicos cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 66
01 Seleccionar médico en el sistema
02 Mostrar pantalla de ingreso de médicos
03 Ingresar nuevo medico
04 Mostrar Código del medico
05 Mostrar lista de centros médicos
06 Ingresar código de centro medico
07 Ingresar matricula del medico
08 Ingresar nombre del medico
09 Ingresar teléfono del medico
10 Validar datos del médico
11 Guardar datos del médico
12 Realizar los pasos 03-10 hasta terminar de cargar los datos
13 Emitir mensaje de éxito de la operación.
Caso de Excepción
10 Validar DNI del Conductor
10.1 Informar ítems vacíos o ingresados pero no
válidos
10.2 Volver al paso 02
Figura C8.F18: Caso de Uso: Ingresar médicos en el sistema
CU: 18 Ingresar examinadores en el sistema
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Examinadores cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de examinadores en el
sistema
02 Mostrar pantalla de ingreso de examinadores
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 67
03 Ingresar nuevo examinador
04 Mostrar Código del examinador
05 Mostrar lista de centros examinadores
06 Ingresar código del centro examinador
07 Ingresar DNI del examinador
08 Ingresar nombre del examinador
09 Ingresar teléfono del examinador
10 Validar datos de examinador
11 Guardar datos de examinador
12 Realizar los pasos 03-10 hasta terminar de cargar los examinadores
13 Emitir mensaje de éxito de la operación.
Caso de Excepción
10 Validar datos del examinador
10.1 Informar ítems vacíos o ingresados pero no
válidos
10.2 Volver al paso 02
Figura C8.F19: Caso de Uso: Ingresar examinadores en el sistema
CU: 19 Consultar estado de solicitud del carnet de conducir
Actor: Usuario
Evento Inicial:
Precondiciones: Logeado en Sistema, Solicitud Iniciado.
Post condiciones: Consulta registrado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar consulta de estado de solicitud del
carnet de conducir
02 Mostrar pantalla de consulta de solicitud
03 Iniciar consulta
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 68
04 Guardar inicio de consulta
05 Mostrar consulta de estado de solicitud
06 Imprimir consulta
07 Guardar fecha y hora de impresión
08 Cerrar consulta
09 Emitir mensaje de éxito de la operación.
Figura C8.F20: Caso de Uso: Consultar estado de solicitud del carnet de conducir
CU: 20 Ingresar condiciones de recupero de puntos.
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Condiciones de recupero de puntos cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de condiciones de recupero
de puntos
02 Mostrar pantalla de condiciones de recupero
de puntos
03 Ingresar nueva condición
04 Mostrar Código de la condición de recupero
de puntos
05 Mostrar lista de categoría
06 Ingresar categoría
07 Ingresar descripción de condición
08 Ingresar puntos a la condición
09 Validar condición ingresada
10 Guardar condición
11 Realizar los pasos 03-10 hasta terminar de cargar las condiciones
12 Emitir mensaje de éxito de la operación.
Caso de Excepción
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 69
09 Validar condición ingresada
09.1 Informar ítems vacíos o ingresados pero no
válidos
09.2 Volver al paso 02
Figura C8.F21: Caso de Uso: Ingresar condiciones de recupero de puntos.
CU: 21 Ingresar condiciones de recupero niveles de carnet de conducir.
Actor: Administrador
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Condiciones de recupero de niveles de carnet de conducir cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de condiciones de recupero
niveles de carnet de conducir
02 Mostrar pantalla de condiciones de recupero
de recupero niveles de carnet de conducir
03 Ingresar nueva condición
04 Mostrar Código de la condición de recupero
de recupero niveles de carnet de conducir
05 Mostrar lista de categoría
06 Ingresar categoría
07 Ingresar descripción de condición
08 Validar condición ingresada
09 Guardar condición
10 Realizar los pasos 03-09 hasta terminar de cargar las condiciones.
11 Emitir mensaje de éxito de la operación.
Modificar poniendo fechas a las condiciones. Como el caso que en un temporada x se libere algunas condiciones
para recuperar puntos.
Caso de Excepción
08 Validar condición ingresada
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 70
08.1 Informar ítems vacíos o ingresados pero no
válidos
08.2 Volver al paso 02
Figura C8.F22: Caso de Uso: Ingresar condiciones de recupero niveles de carnet de conducir
CU: 22 Ingresar nueva infracción en el sistema.
Actor: Usuario
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Nueva infracción cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de nueva infracción
02 Mostrar pantalla de ingreso de infracción
03 Seleccionar nueva infracción
04 Ingresar patente del vehículo
05 Ingresar DNI del conductor (opcional)
06 Ingresar código de infracción
07 Validar infracción ingresada
08 Identificar y guardar ubicación geográfica
09 Guardar ID usuario Logeado
10 Guardar infracción
11 Realizar los pasos 03-10 hasta terminar de cargar las condiciones.
12 Emitir mensaje de éxito de la operación.
Caso de Excepción
07 Validar infracción ingresada
07.1 Informar ítems vacíos o ingresados pero no
válidos
07.2 Volver al paso 02
Figura C8.F23: Caso de Uso: Ingresar nueva infracción en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 71
CU: 23 Ingresar solicitud de recupero de puntos
Actor: Usuario
Evento Inicial: Logeado en Sistema
Precondiciones:
Post condiciones: Nueva solicitud de recupero de puntos cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de solicitud de recupero de
puntos.
02 Mostrar pantalla de solicitud de recupero de
puntos
03 Seleccionar nueva solicitud de recupero de
puntos
04 Validar selección de solicitud
05 Generar código de solicitud de recupero de
puntos
06 Generar lista de condiciones correspondiente
a la categoría del carnet de conducir
07 Imprimir lista de condiciones
08 Guardar fecha hora de impresión de las
condiciones
09 Emitir mensaje de éxito de la operación.
Caso de Excepción
04 Validar selección de solicitud
04.1 Informar selección de solicitud no realizada
04.2 Volver al paso 02
Figura C8.F24: Caso de Uso: Ingresar solicitud de recupero de puntos
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 72
CU: 24 Ingresar solicitud de recupero de nivel de categoría
Actor: Usuario
Evento Inicial:
Precondiciones: Logeado en Sistema
Post condiciones: Nueva solicitud de recupero de nivel de categoría cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de solicitud de recupero de
nivel de categoría.
02 Mostrar pantalla de solicitud de recupero de
puntos
03 Seleccionar nueva solicitud de recupero de nivel
de categoría
04 Validar selección de solicitud
05 Generar código de solicitud de recupero de
nivel de categoría
06 Generar lista de condiciones correspondiente
a la categoría del carnet de conducir.
07 Imprimir lista de condiciones
08 Guardar fecha hora de impresión de las
condiciones
09 Emitir mensaje de éxito de la operación.
Caso de Excepción
04 Validar selección de solicitud
04.1 Informar selección de solicitud no realizada
04.2 Volver al paso 02
Figura C8.F25: Caso de Uso: Ingresar solicitud de recupero de nivel de categoría
6
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 73
1.4 Diagrama de Clases
Según se desarrollan cada uno de los casos de uso, se visualiza la presencia
de algunas clases y sus relaciones entre ellas, sin especificar todavía las propiedades
y los métodos de cada uno.
Figura C8.F26: Diagrama de Clases. Luego de terminar de desarrollar los casos de uso.
1.5 Primer diseño de interfaz
A esta altura del desarrollo, el diseño ya se visualiza con detalles generales y
se puede obtener la primera pantalla de captura de datos, al tener en cuenta:
- Las pantallas de interacción con el usuario deben ser sencillas y con muy
pocos controles, para incentivar el uso del sistema directamente desde la web.
- Es necesaria la inclusión de un sistema completo en cada municipalidad, para
la captura de la imagen fotográfica y de las huellas digitales, dando oportunidad
a personas que no se animen al uso de internet para hacer sus trámites.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 74
Figura C8.F27: Primera impresión de la pantalla de captura de datos del conductor.
Al término de la iteración 2 se produce una revisión de grande del diagrama de
Casos de Uso, una revisión inicial de las clases y el diseño de una de la pantalla inicial
estimada en ese momento.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Iteraciones
Diagrama de Diseño
Análisis
Iteración 1
Iteración 2
Iteración 3
Iteración 4
Diseño Iteración 5
Iteración 6
Tabla C8.T2: Tabla de Diagramas en esta iteración
Facultad de Ciencias Exactas
______________________________________________________________ Iteración 3: Corrección de Casos
1. Corrección de Casos de Uso
1.1 Diagrama de Clases
Al intentar avanzar con el diagrama de clases,
se observa que este diagrama no está totalmente desarrollado y que
revisar algunos casos de uso, modificando el nombre o el escenario de éxito.
Figura C9.F1: Diagr
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Iteración 3: Corrección de Casos de Uso - Modelo de Clases
Corrección de Casos de Uso - Modelo de Clases
avanzar con el diagrama de clases, previa revisión de cada clases,
que este diagrama no está totalmente desarrollado y que es necesario
revisar algunos casos de uso, modificando el nombre o el escenario de éxito.
Figura C9.F1: Diagrama de Clases correspondiente al comienzo de la iteración 3.
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 75
ión de cada clases,
es necesario
revisar algunos casos de uso, modificando el nombre o el escenario de éxito.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 76
1.2 Casos de Uso
Después de la primera visualización del diagrama de clases, se revisa
nuevamente la lista de funciones de casos de uso más críticos y refinar a algunos de
ellos nuevamente, el resto no se analiza por el momento, y se espera una nueva
actualización del diagrama de clases.
Nº Caso de Uso
01 El solicitante ingresa solicitud online de carnet de conducir
06 El solicitante realiza examen teórico
09 Cargar fotografía en el sistema – Eliminado en esta Iteración
09 Administrador Actualiza y verifica datos personales en el sistema
10 Cargar huella digital en el sistema – Eliminado en esta Iteración
11 Administrador actualiza preguntas en el sistema
13 El usuario ingresa reglamento de puntos al sistema
18 El administrador ingresa examinador en el sistema
22 Agente ingresa nueva infracción en el sistema
25 El Solicitante se inscribe en el sistema.
Tabla C9.T1: Lista de casos de usos que desarrollamos en esta iteración.
Para todos los casos de uso, en el cual se hace referencia a un usuario, puede
ser un administrador, un conductor, un administrativo y siempre depende de los
privilegios que el usuario tenga.
Después de revisar la lista de casos de uso se concluye:
El caso de uso número 9 y 10 se unifican en esta iteración, al
considerarlos que corresponden a una misma acción que actualiza los
datos del solicitante del carnet de conducir. Se renombra el caso de uso
número 9 y eliminar el número 10.
El caso de uso número 11 se modifica de usuario a usuario
Administrador, y se cambia el nombre del caso de uso a “Administrador
actualiza preguntas en el sistema”.
El caso de uso número 13 también debe ser cambiado de usuario a
Administrador, pero se deja ese nombre para poder distinguir a usuarios
a manipular el sistema con distintos privilegios.
El caso de uso número 25 no se desarrolla en las primeras iteraciones,
por considerarlo no importante a los fines del seminario. Pero en una
nueva iteración se debe agregarlo nuevamente, para poder luego
visualizar la pantalla de captura de los datos del conductor y así poder
entender aun más el diagrama de clases.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 77
1.2.1 Casos de Uso resultantes en esta iteración
CU: 01 El solicitante ingresa solicitud online del carnet de conducir
Actor: Administrador
Evento Inicial: Se solicita inicio de trámites en el Sistema
Precondiciones: Usuario autenticado en el sistema
Post condiciones: Solicitud iniciada. Primera etapa del trámite terminado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar Opción generación del carnet
de conducir
02 Desplegar diferentes categorías y el tipo del
carnet de conducir correspondiente al Usuario
ingresado (por colores).
03 Elegir UNA categoría
04 Detallar Instituciones disponibles para examen
teórico
05 Detallar calendario con fechas disponibles para el
examen teórico
06 Elegir lugar y fecha de las opciones
disponibles.
07 Detallar Instituciones disponibles para examen
práctico
08 Detallar calendario con fechas disponibles para el
examen práctico
09 Elegir lugar y fecha de las opciones
disponibles.
10 Detallar Instituciones disponibles para examen
médico
11 Detallar calendario con fechas disponibles para el
examen médico
12 Elegir lugar y fecha de las opciones
disponibles.
13 Validar ítems seleccionados
14 Mostrar pantallas con las opciones elegidas.
15 Generar Exámenes
16 Registrar datos ingresados.
17 Generar transacciones por cada una de las
opciones elegidas.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 78
18 «include» Incluye Caso de Uso 05 “Generar ticket
de pago”
19 Repetir los pasos 17-18 hasta haber generado los tickets por las opciones elegidas.
20 Mostrar los tickets a pagar correspondientes a las
opciones elegidas.
21 Imprimir tickets.
22 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
13 Validar ítems seleccionados
13.1 Informar ítems vacíos o ingresados pero no
válidos
13.2 Volver al paso 02
Figura C9.F2: Caso de Uso: El solicitante ingresa solicitud online de solicitud del del carnet de conducir
CU: 09 Administrador Actualiza y verifica datos personales en el sistema
Actor: Conductor
Evento Inicial:
Precondiciones: Logeado en Sistema, Administrador autenticado en el sistema, Conductor ya
registrado en el sistema
Post condiciones:
Registración de datos del conductor completada.
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Ingresar DNI del Conductor
02 Validar DNI del Conductor
03 Seleccionar opción carga de fotografía
04 Mostrar inicio de captura de fotografía
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 79
05 Cargar y guardar imagen
06 Mostrar foto cargada
07 Repetir los pasos 4-6 hasta determinar la foto a usar
08 Validar Fotografía ingresada
09 Guardar Fotografía
10 Seleccionar opción carga de huella dactilar
11 Cargar de Huella Dactilar
12 Mostrar huella dactilar digitalizada
13 Repetir los pasos 11-12 hasta determinar la huella dactilar a usar
14 Validar huella Digital capturada
15 Guardar huella dactilar
16 Actualizar datos personales de otro sistema
de datos personales
17 Actualizar estado de datos personales
18 Emitir mensaje de éxito de la operación.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
08 Validar Fotografía ingresada
08.1 Informar fotografía ingresada no válido
08.2 Volver al paso 04
Caso de Excepción
14 Validar huella Digital capturada
14.1 Informar huella digital no válida
14.2 Volver al paso 10
Figura C9.F3: Caso de Uso: Ingresar solicitud online de solicitud del carnet de conducir
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 80
CU: 13 Ingresar reglamento de los puntos en el sistema
Actor: Usuario
Evento Inicial:
Precondiciones: Logeado en Sistema, Infracciones ya cargadas en el sistema.
Post condiciones: Reglamento cargado
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de reglamento de los puntos
en el sistema.
02 Mostrar pantalla de ingreso de reglamentos a
infracciones
03 Mostrar Pantalla de ingreso de código de
infracción.
04 Ingresar código de infracción
05 Mostrar pantalla de ingreso de reglamento
06 Seleccionar nuevo reglamento
07 Mostrar Código del reglamento
08 Ingresar descripción del punto
09 Ingresar puntos a descontar
10 Validar reglamento ingresado
11 Guardar reglamento
12 Realizar los pasos 02-11 hasta terminar de cargar los reglamentos a la infracción
13 Emitir mensaje de éxito de la operación.
Caso de Excepción
10 Validar reglamento ingresado
10.1 Informar ítems vacíos o ingresados pero no
válidos
10.2 Volver al paso 02
Figura C9.F4: Caso de Uso: Ingresar reglamento de los puntos en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 81
CU: 22 Ingresar nueva infracción en el sistema.
Actor: Usuario
Evento Inicial:
Precondiciones: Agente Logeado en el sistema
Post condiciones:
Nueva infracción cargado en el sistema
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de nueva infracción en el
sistema
02 Mostrar pantalla de ingreso de infracción
03 Seleccionar nueva infracción
04 Ingresar patente del vehículo
05 Ingresar DNI del conductor (opcional)
06 Ingresar código de infracción
07 Guardar ubicación geográfica (GPS)
08 Guardar ID usuario Logeado
09 Validar infracción ingresada
10 Guardar infracción
11 Realizar los pasos 03-10 hasta terminar de cargar las condiciones.
12 Emitir mensaje de éxito de la operación.
En las situaciones donde la persona a la cual se le procede a hacer una infracción no está registrada, se registra el
número de documento nacional de identidad, para poder ya crear el historial de la persona en cuestión. Este caso
deberá ser estudiado con más profundidad, en el caso por ejemplo, que el conductor no posea un carnet de
conducir y su documento nacional de identidad no sea verdadero.
Caso de Excepción
02 Validar DNI del Conductor
02.1 Informar DNI ingresado no válido
02.2 Volver al paso 01
Caso de Excepción
09 Validar infracción ingresada
09.1 Informar ítems vacíos o ingresados pero no
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 82
válidos
09.2 Volver al paso 02
Figura C9.F5: Caso de Uso: Ingresar nueva infracción en el sistema
CU: 25 Ingresar inscripción en el sistema
Actor: Conductor
Evento Inicial: Ninguno
Precondiciones: Ninguno
Post condiciones: Conductor registrado en el sistema.
Escenario Principal de Éxito.
Acciones Actor Principal Acciones Sistema
01 Seleccionar ingreso de inscripción en el sistema.
02 Mostrar pantalla de bienvenida al sistema
digital de carnet de conducir.
03 Seleccionar inscripción en el sistema.
04 Mostrar Pestaña de formulario para cargar
Datos Personales.
05 Cargar datos en la pestaña de Datos personales.
06 Mostrar Pestaña de formulario para cargar
Datos relacionados al domicilio que figura en
el DNI.
07 Cargar datos en la pestaña de formulario para
cargar Datos relacionados al domicilio.
08 Mostrar Pestaña de formulario para cargar
Datos relacionados al logeo en el sistema.
09 Cargar datos en la pestaña de formulario para
cargar datos de logeo.
10 Validar datos de inscripción
10 Guardar datos de inscripción
11 Enviar datos y actividad realizada al correo
electrónico del conductor ingresado
previamente.
12 Emitir mensaje de éxito de la operación.
Notas: El usuario de acceso al sistema, estará compuesto de tipo de documento y el número de documento de
identidad. El correo electrónico no es un dato requerido al momento de la inscripción, pero se lo considera
importante, porque será además de notificación y comunicación con el conductor sobre cada cambio, turnos,
resultados y toda acción que amerite una comunicación con el titular de la cuenta. El sistema cuenta con una línea
telefónica para aquellos casos en donde el usuario no pueda acceder al sistema y no pueda recuperar la
contraseña por los medios convencionales (Envío de contraseña al correo electrónico).
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 83
Casos de Excepción
10 Validar datos de inscripción
10.1 Informar ítems vacíos o ingresados pero no
válidos
10.2 Volver al paso 02
Figura C9.F6: Caso de Uso: Ingresar inscripción en el sistema
1.4 Conclusión al término de las iteraciones para el Análisis
Hasta ahora, después de escribir la mayoría de los casos de uso se ha
encontrado la mayoría de los actores que van a ser necesarios en esta parte del
análisis: el administrador, el solicitante, el examinador que puede ser el mismo en el
caso de examen teórico o práctico, el médico, el sistema bancario, etc.
Algunos de los casos de uso se escriben con mayor detalle, por considerarse
que son críticos o necesarios para entender la acción a desarrollar.
El sistema debe ser funcional, por lo tanto se va a tener que gestionar un
control y almacenamiento de errores, para luego mejorar o evitar que los mismos
ocurran nuevamente. Debe tener una facilidad de uso, como por ejemplo la pantalla en
la captura de datos, la cual debe ser amigable con el usuario. Debe ser fiable; se
conoce que el usuario debe hacer pagos en algún momento, por lo tanto es necesario
contar con seguridad informática, para el pago con tarjetas de crédito o débito. Esta
sección de pago es un subsistema que debe ser implementado en el sistema para
tener finalmente un sistema integrado. El rendimiento es observable cuando se
observa a simple vista, que muchos trámites se agilizaron al dejar de usar el papel
tradicional y se automatizaron.
El diagrama de clases de dominio, en el cual se mostrará en resumen, las clases y las relaciones entre ellas en el sistema objeto de estudio, incluyendo las direcciones de las flechas, que nos muestran el sentido de las consultas y las asociaciones bidireccionales. A las relaciones se las asocia una multiplicidad, expresada “en el lado opuesto” de la relación, que resume el número de posibles instancias de una clase asociada o única instancia de la clase con el otro extremo. [ASI2006]
El diagrama a continuación muestra el nombre de las clases y sus relaciones,
sin tener en cuenta a primera vista, los métodos y atributos, ya que no se tiene con
demasiada precisión en este momento de a cada uno de ellos.
En una segunda iteración, se revisa las clases encontradas y se genera
nuevamente una refinación para obtener cada vez más detalles; por ejemplo, el
solicitante es ahora en más un conductor, antes que este haga un examen, debe
tener iniciada una solicitud de carnet de conducir y esta solicitud a su vez tiene una
lista de exámenes a realizar.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 84
Cada usuario conductor, que es un objeto de una clase Usuario, tiene una lista
de actividades, que son todas las acciones que realice en el sistema, tales como inicio
de una solicitud de carnet de conducir, consultar resultados, etc. Además una lista de
infracciones, y que por la cual se conoce a su vez, su antecedente.
La clase Banco contiene a su vez a todos los organismos en las que se pueden
realizar pagos, sea este un banco u operadores de pago como los conocidos
“rapipagos” y que se asociará a tickets pagados y estos a a órdenes de pago por
infracciones, por exámenes y cualquier otro pedido de pago por el sistema.
Las clases “tipo”, TipoExamen, TipoCedula no se incluye en este diagrama ni
en los siguientes porque no aportan un dato significativo en el desarrollo y estudio,
pero son de vital importancia para la clasificación de clases en el sistema
Finalmente luego de desarrollar los casos de usos, se tiene en vista, un nuevo
diagrama de Clases. El proceso unificado del desarrollo de software muestra ser un
proceso “iterativo e incremental”
Figura C9.F7: Diagrama de Clases al termino de esta iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 85
Al término de la Iteración 3, se termina de revisar los Casos de Uso, ampliado
de esta manera las clases encontrado más relaciones entre ellos.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Iteraciones
Diagrama de Diseño
Análisis
Iteración 1
Iteración 2
Iteración 3
Diseño
Iteración 4
Iteración 5
Iteración 6
Tabla C9.T2: Tabla de Diagramas en esta iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 86
Capítulo VI
Diseño
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 87
Iteración 4: Diagramas de Iteración
1. Diagramas
1.1 Diagramas de Interacción [CLAR-UMLP2002]
El término diagrama de interacción es una generalización de dos tipos de
diagramas UML mas especializados: ambos pueden utilizarse para representar de
forma similar interacciones de mensajes:
Diagrama de secuencia: ilustran las interacciones de un tipo de formato con
el aspecto de una valla.
Diagrama de colaboración: ilustran las interacciones entre objetos en un
formato de grafo o red, en el cual los objetos se pueden colocar en
cualquier lugar del diagrama.
Puntos fuertes Puntos débiles
Diagramas de Secuencia
Muestra claramente la secuencia u
ordenación en el tiempo de los
mensajes
Notación simple
Fuerza a extender por la derecha
cuando se añaden nuevos objetos,
consume espacio horizontal
Diagrama de Colaboración
Economiza espacio, flexibilidad al
añadir nuevos objetos en dos
dimensiones
Es mejor para ilustrar bifurcaciones
completas, iteraciones y
comportamiento concurrente
Difícil ver la secuencia de mensaje
Notación más compleja
Tabla C10.T1: Comparación entre puntos fuertes y débiles Diagramas de Secuencia y de Colaboración
1.2 Lista de Diagramas de Interacción
Por tratarse de un sistema donde la interacción de los mensajes no prevé
muchas bifurcaciones, los diagramas de iteración serán usados en este estudio.
Todos los diagramas descritos a continuación tienen un mensaje a la clase
Actividad, esto pone en énfasis la necesidad de registrar dicha acción, aun cuando la
misma sea un proceso de consulta en el sistema, por parte del administrador o
usuario conductor.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 88
En la figura [Figura C10.F1] se hace referencia a un mensaje “RegistrarActividad()” y
la misma es un método que resultará dependiendo de quien haya enviado el mensaje,
aquí es donde se muestra el polimorfismo y su capacidad para que
varias clases derivadas de una antecesora utilicen un mismo método de forma
diferente.
Figura C10.F1: Diagrama de Iteración: Usuario Registra Actividad en el Sistema.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 89
Figura C10.F2: Diagrama de Iteración: Usuario Administrador Actualiza el reglamento para el descuento de puntos.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 90
Figura C10.F3: Diagrama de Iteración: Usuario Actualiza los puntos a una categoría
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 91
Figura C10.F4: Diagrama de Iteración: Agente de Transito crea nueva infracción
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 92
Figura C10.F5: Diagrama de Iteración: Administrador actualiza preguntas y posibles respuestas
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 93
Figura C10.F6: Diagrama de Iteración: Administrador Actualiza examinadores en el sistema.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 94
Figura C10.F7: Diagrama de Iteración: Administrador valida datos personales del conductor y la información queda actualizada para
poder ser usada oficialmente.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 95
Figura C10.F8: Diagrama de Iteración: Conductor realiza Examen teórico
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 96
Figura C10.F9: Diagrama de Iteración: Examinador completa los resultados del examen. Caso de aplicación
Médico: Examen
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 97
Figura C10.F10: Diagrama de Iteración: Conductor se inscribe en el sistema
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 98
Figura C10.F11: Diagrama de Iteración: Usuario inicia Solicitud
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 99
1.3 Diagramas de Clases
Figura C10.F12: Diagrama de Clases al final de esta iteración.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 100
Al término de la iteración 4, se realizan los diagramas de iteración dando
nuevamente un avance en el desarrollo de las clases y el diagrama final del mismo.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Iteraciones
Diagrama de Diseño
Análisis
Iteración 1
Iteración 2
Iteración 3
Diseño
Iteración 4
Iteración 5
Iteración 6
Tabla C10.T2: Tabla de Diagramas en esta iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 101
Iteración 5: Diagramas de Iteración - Clases
1.1 Lista de Diagramas de Interacción
Figura C10.F12: Diagrama de Iteración: Agente genera una nueva infracción – Segunda Iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 102
Figura C10.F13: Diagrama de Iteración: Usuario inicia Solicitud – Segunda Iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 103
1.2 Lista de Pantallas
Sistema: Sistema Emisor de
Carnet de Conducir
Módulo: Datos Personales Proceso: Actualización
de Datos Personales
del Solicitante P1 Autor: J.R.E.D. Fecha: Julio/2011
Referencias:
Figura C10.F14: Pantalla para el Administrador para la aplicación de las infracciones manualmente.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 104
Sistema: Sistema Emisor de
Carnet de Conducir
Módulo: Datos Personales Proceso: Listado de
Módulos a actualizar
por el Administrador P2 Autor: J.R.E.D. Fecha: Julio/2011
Referencias:
Figura C11.F15: Pantalla de Validaciones a realizar por el administrador
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 105
Sistema: Sistema Emisor de
Carnet de Conducir
Módulo: Datos Personales Proceso: Listado de
Turnos y Resultado de
examen realizado P3 Autor: J.R.E.D. Fecha: Julio/2011
Referencias:
Figura C10.F16: Pantalla de turnos para exámenes
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 106
1.3 Diagrama de Clase
Algunas veces cuando se trabaja en los casos de uso donde el usuario y/o
administrador agrega las condiciones de los puntos en el sistema, fue casi
intuitivamente agregar una relación en el diagrama de clases entre la clase usuario y la
clase puntos, pero después de pensarlo mejor, un usuario administrador no posee
puntos, ni tampoco la clase carnet de conducir, los puntos lo tiene la clase conductor.
Esto hizo que se modifique constantemente el diagrama de clases
Aun cuando se desarrollaba los diagramas de iteración, se necesitó hacer
cambios en el diagrama de clases, y finalmente mostrar también con sus propiedades
y métodos.
Figura C10.F17: Diagrama de Clases – Clases no Expandidas - Final
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 107
Se realiza las primeras pantallas, se corrige los diagramas de iteraciones
dando mayor información para revisar nuevamente las clases casi definitivas.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Iteraciones
Diagrama de Diseño
Análisis
Iteración 1
Iteración 2
Iteración 3
Diseño
Iteración 4
Iteración 5
Iteración 6
Tabla C10.T1: Tabla de Diagramas en esta iteración
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 108
Iteración 6: Diseño de Interfaz
1. Interfaces del Sistema
1.1 Diseño de la Interfaz
Se tiene en cuenta algunos principios: [ASI2006]
Interfaz debe ser consistente. (Por ejemplo Menú Administrador Figura
C11.F1 – Menú Usuario Fig. C11.F9)
Proveer al usuario de retroalimentación. (Por ejemplo Estado de examen
Fig. C11.F15)
Verificar acciones destructivas “¿Está seguro de aplicar los cambios?”
(Por ejemplo Figura C11.F14 a pedido de la Fig. C11.F4)
Permitir al usuario arrepentirse y volver atrás. (Por ejemplo Botón
“Cancelar” Fig. C11.F13)
Reducir la cantidad de memoria del usuario necesario para operar en el
sistema. (por ejemplo la distribución de los datos en el menú del usuario.
Fig. C11.F9)
Buscar eficiencia en el diálogo, y el accionar de los usuarios. (Por
ejemplo grillas con diversa información y link “Editar” por cada fila Fig.
C11.F7)
Perdonar errores. (Por ejemplo al intentar guardar cambios y existan
campos obligatorios sin completar, se deberá conservar datos ya
ingresados. Fig. C11.F9)
Categorizar las actividades y respetar la geografía de la pantalla. (Por
ejemplo en caso de modificar esta pantalla. Fig. C11.F9)
Proveer al usuario siempre de ayuda, si es posible sensible al contexto.
(Por ejemplo carga de mapa con la dirección del domicilio ingresado.
Fig. C11.F10)
Utilizar verbos simples para describir acciones que puede realizar el
usuario (Por ejemplo nombres de botones o link. Fig. C11.F15)
1.2 Principios para visualización de la información
Mostrar solo la información relevante.
No abrumar al usuario con detalles.
Utilizar etiquetas adecuadas y consistentes
Mantener el contexto visual
Usar mayúsculas y minúsculas en el diseño de etiquetas
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 109
En lo posible usar concepto de ventana
Utilizar representaciones análogas, si amerita
Mantener esquema de la pantalla (geografía).
1.3 Entradas de datos
Minimizar la cantidad de acciones que debe hacer el usuario
Mantener consistencia entre lo que se entrega y se ve
Permitir al usuario, personalizar la entrada de datos
Desactivar las órdenes no permitidas o fuera de contexto
Permitir al usuario el control del programa
Asistir al usuario con ayuda en todo momento
Eliminar el ingreso de datos innecesarios
1.4 Diseño Entrada, Salida y Control
Entrada
Contenido
Codificación
Medio (de captura de datos)
Disposición y formato
Tratamiento de errores
Validaciones
Salida
Contenido – con respeto a la pirámide organizacional
Medio – si hay menos papel- mejor
Formato – columnas, título de página, índices
Distribución – tiempo y forma
Control
Validación de la transacción
o Incompleta
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 110
o No existe autorización
o Fuera de lugar
Validación de los datos de la transacción
o Existencia
o Límites y rangos
o Relación con otros datos
1.5 PDF147
Cada carnet de conducir va a tener una banda de código de barras, que
contendrá la información detallada del carnet. De los distintos tipos de códigos de
barras se considera que el tipo ideal es el PDF147, que es un código de longitud
variable que puede codificar virtualmente cualquier letra, número o carácter. Cada
carácter consiste de 4 barras y 4 espacios en una estructura de 17 módulos. El
nombre de la simbología se deriva del formato del código. PDF significa “Portable Data
File” (“Archivo Portátil de Datos”) y “417” se deriva de la estructura del módulo. Cada
PDF417 consiste de 3 a 90 renglones apilados rodeados por una zona quieta en cada
uno de los 4 lados. Cada renglón consiste de una zona quieta inicial, un patrón de
lectura, un carácter indicador de la columna izquierda, uno a 30 caracteres de datos,
un carácter indicador de la columna derecha, patrón de alto, y una zona quieta final.
El código PDF417 soporta compactación de texto, de números, y de bytes con
una capacidad máxima de 1.850 caracteres o 1.100 códigos binarios por cada símbolo
(cada rectángulo en forma de “nube de puntos”). Una vez fijada la anchura del
símbolo, su altura depende de la información incorporada. Si la cantidad de
información a almacenar es mayor de la que cabe en un símbolo, pueden enlazarse
varios hasta superar el espacio de almacenamiento necesario.
Se utiliza en etiquetas de transporte cuando la información conviene que esté
disponible aunque no se pueda acceder al sistema en el que se controla el flujo
logístico. También cuando es imprescindible disponer de un instrumento en papel
(tarjeta de plástico, como un carnet) cuya información interese leer de forma ágil, con
la ayuda de un lector especializado.
Para imprimir el código PDF-417 se puede usar impresoras láser, térmicas o de
chorro de tinta (en este caso hay que cuidar la calidad del papel).
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 111
1.6 Diagrama de Clases
Figura C11.F1: Diagrama de Clases al final de esta iteración.
Facultad de Ciencias Exactas
______________________________________________________________
1.7 Lista de Pantallas
Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada OUT: Datos de Salida Grilla: Lista de todos los módulos, la edición de estas pantallas diferentes.P09: Abre la pantalla “P09”, para poder autorizar la información y cambiar el estado a “Actualizado”P10: Abre la pantalla “P10”, para poder autorizar la información y cambiar el estado a “Actualizado”P12: Abre la pantalla “P12”, para poder autorizar la información y cambiar el estado a “Actualizado”
Figura C11.F2: Pantalla para el Administrador con acceso a pestaña Validaciones.
OUT
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Validaciones de
Solicitudes
Proceso: Listado de
módulos a actualizar por
el Administrador
Fecha: Septiembre/2011
: Lista de todos los módulos, la edición de estas pantallas diferentes. Abre la pantalla “P09”, para poder autorizar la información y cambiar el estado a “Actualizado”
rizar la información y cambiar el estado a “Actualizado” : Abre la pantalla “P12”, para poder autorizar la información y cambiar el estado a “Actualizado”
: Pantalla para el Administrador con acceso a pestaña Validaciones.
P09
P10
P12
OUT
IN
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 112
Listado de
módulos a actualizar por P01
OUT
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida Grilla: Lista de todas las categorías, la edición se hace en una misma pantalla.P03: Abre la pantalla “P03”, para completar los datos para los reglamento de una categoría.
Figura C11.F3: Pantalla para el Administrador con acceso a pestaña Reglamentos por
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Reglamento por
Categoría
Proceso:
Actualización de los
reglamentos y
puntos a descontar Fecha: Septiembre/2011
categorías, la edición se hace en una misma pantalla. completar los datos para los reglamento de una categoría.
: Pantalla para el Administrador con acceso a pestaña Reglamentos por Categoría.
P03
P03
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 113
P02
OUT
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida Grilla: Lista de todos los reglamentos, la edición se hace en una misma pantalla.P04: Abre la pantalla “P04”, para poder completar los datos de un reglamento y las listas de infracciones que tenga relación.B01: Guarda los cambios hechos a una categoría y vuelve a la pantalla “P02B02: Deja sin efecto los cambios hechos a una categoría y vuelve a la pantalla “P02”
Figura C11.F4: Pantalla para el Administrador con acceso a
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Lista de Reglamentos
agrupadas por
Categoría
Proceso:
Actualización de
Categoría y
modificación de
reglamentos Fecha: Septiembre/2011
reglamentos, la edición se hace en una misma pantalla. completar los datos de un reglamento y las listas de infracciones que tenga relación.
Guarda los cambios hechos a una categoría y vuelve a la pantalla “P02” Deja sin efecto los cambios hechos a una categoría y vuelve a la pantalla “P02”
: Pantalla para el Administrador con acceso a la actualización de Reglamentos por Categoría
P04
OUT
OUT
P04
B01
B02
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 114
P03
completar los datos de un reglamento y las listas de infracciones que tenga relación.
Categoría.
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada OUT: Datos de Salida Grilla: Lista de todas las infracciones que producirá la aplicación de este reglamentoconfirmación de acción. B01: Guarda los cambios hechos a un reglamentB02: Deja sin efecto los cambios hechos a un reglamento B03: Agrega la infracción seleccionada a la grilla, vinculando esa infracción al reglamento.P14: Abre la pantalla “P14”, elimina la infracción seleccionada, disminuyendo en uno la cantidad de infracciones para ese reglamento.
Figura C11.F5: Pantalla para el Administrador con acceso a la actualización de un Reglamento en particular.
IN
OUT
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Reglamento y lista de
infracciones
asociadas
Proceso: Actualización
del Reglamento y las
infracciones asociadas
Fecha: Septiembre/2011
las infracciones que producirá la aplicación de este reglamento, la edición se hace en una misma pantalla
a un reglamento y vuelve a la pantalla “P03” a un reglamento y vuelve a la pantalla “P03”
Agrega la infracción seleccionada a la grilla, vinculando esa infracción al reglamento. infracción seleccionada, disminuyendo en uno la cantidad de infracciones para ese reglamento.
: Pantalla para el Administrador con acceso a la actualización de un Reglamento en particular.
OUT
IN
IN
IN
OUT
OUT
B01
B02
P14
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 115
Actualización
infracciones asociadas P04
, la edición se hace en una misma pantalla de
infracción seleccionada, disminuyendo en uno la cantidad de infracciones para ese reglamento.
: Pantalla para el Administrador con acceso a la actualización de un Reglamento en particular.
B03
Facultad de Ciencias Exactas
______________________________________________________________
Sistema: Sistema Emisor de
Carnet de Conducir Módulo:
Autor: J.R.E.D. Fecha:
Referencias:
OUT: Datos de Salida Grilla: Lista de todos las categorías y su asociación con preguntas, mostrando la cantidad de preguntas activas y aquellas que no se publicaron. P06: Abre la pantalla “P06”, muestra una lista de preguntas asociada a la categoría.
Figura C11.F6: Pantalla para
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Categorías asociadas
a preguntas.
Proceso:
Actualización de
Categorías
asociadas a
preguntas Fecha: Septiembre/2011
categorías y su asociación con preguntas, mostrando la cantidad de preguntas activas y aquellas que no se
muestra una lista de preguntas asociada a la categoría.
: Pantalla para el Administrador con acceso a la pestaña Preguntas Categoría.
P06
P06
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 116
P05
categorías y su asociación con preguntas, mostrando la cantidad de preguntas activas y aquellas que no se
OUT
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada OUT: Datos de Salida Grilla: Lista de todos las preguntas correspondiente a la actual categoría.P07: Abre la pantalla “P07”, muestra una lista de B01: Guarda los cambios hechos a una categoría y vuelve a la pantalla “P05”B02: Deja sin efecto los cambios hechos a una categoría y vuelve a la pantalla “P05”
Figura C11.F7: Pantalla para el Administrador con acceso a la actualización de Preguntas de una Categoría.
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Lista de Preguntas
asociadas a una
categoría
Proceso: Actualización
de preguntas
asociadas a una
categoría.
Fecha: Septiembre/2011
: Lista de todos las preguntas correspondiente a la actual categoría. ”, muestra una lista de respuestas asociada a la pregunta.
Guarda los cambios hechos a una categoría y vuelve a la pantalla “P05” Deja sin efecto los cambios hechos a una categoría y vuelve a la pantalla “P05”
Pantalla para el Administrador con acceso a la actualización de Preguntas de una Categoría.
OUT
OUT
OUT
OUT
P07
P07
B02
B01
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 117
Actualización
P06
Pantalla para el Administrador con acceso a la actualización de Preguntas de una Categoría.
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada OUT: Datos de Salida Grilla: Lista de todos las preguntas correspondiente a la actual categoría.P08: Abre la pantalla “P08”, muestra en detalle la pregunta a modificar.B01: Guarda los cambios hechos a una pregunta y vuelve a la pantalla “P06”B02: Deja sin efecto los cambios hechos a una pregunta y vuelve a la pantalla “P06”
Figura C11.F8: Pantalla para el Administrad
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Respuestas Asociadas
a Pregunta
Proceso: Lista de
Respuestas asociada a
Preguntas
Fecha: Septiembre/2011
: Lista de todos las preguntas correspondiente a la actual categoría. “P08”, muestra en detalle la pregunta a modificar.
Guarda los cambios hechos a una pregunta y vuelve a la pantalla “P06” Deja sin efecto los cambios hechos a una pregunta y vuelve a la pantalla “P06”
: Pantalla para el Administrador con acceso a la actualización de Respuestas a una Pregunta.
OUT
IN
IN
OUT
P08
P08
B02
B01
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 118
Respuestas asociada a P07
or con acceso a la actualización de Respuestas a una Pregunta.
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada OUT: Datos de Salida B01: Guarda los cambios hechos a una respuestaB02: Deja sin efecto los cambios hechos a una
Figura C11.F9: Pantalla para el Administrador con acceso a la actualización de una Respuesta en particular
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Respuesta Proceso: Actualización
de Respuesta.
Fecha: Septiembre/2011
respuesta y vuelve a la pantalla “P07” Deja sin efecto los cambios hechos a una respuesta y vuelve a la pantalla “P07”
: Pantalla para el Administrador con acceso a la actualización de una Respuesta en particular
OUT
OUT
OUT
IN
IN
IN
IN
B01
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 119
Actualización
P08
: Pantalla para el Administrador con acceso a la actualización de una Respuesta en particular
B02
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada IN ADM: Datos de Entrada, ingresada únicamente por usuario con permiso de administrador.OUT: Datos de Salida B01: Guarda los cambios hechos a los datos PersonalesB02: Deja sin efecto los cambios a los datos Personales B01 ADM: Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta pantalla.B02 ADM: Deja sin efecto los cambios a los datos Personales, volviendo a un estado anterior válido.
Figura C11.F10: Pantalla para el Administrador con acceso a la actualización de Datos personales y de acceso para el conductor para
IN
IN
IN
IN
IN
IN
OUT
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Datos Personales Proceso: Actualización
de Datos Personales
del solicitante
Fecha: Septiembre/2011
Datos de Entrada, ingresada únicamente por usuario con permiso de administrador.
Guarda los cambios hechos a los datos Personales Deja sin efecto los cambios a los datos Personales
ible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta pantalla.Deja sin efecto los cambios a los datos Personales, volviendo a un estado anterior válido.
ra el Administrador con acceso a la actualización de Datos personales y de acceso para el conductor para
modificar sus datos.
IN
IN
IN
OUT
IN ADM
IN ADM
B01
B01OUT
OUT
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 120
Actualización
P09
ible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta pantalla.
ra el Administrador con acceso a la actualización de Datos personales y de acceso para el conductor para
ADM
B02
ADM
B01
ADM
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
IN: Datos de Entrada OUT: Datos de Salida B01: Guarda los cambios hechos al Domicilio B02: Deja sin efecto los cambios hechos al DomicilioB01 ADM: Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta pB02 ADM: Deja sin efecto los cambios a los datos Personales, volviendo a un estado anterior válido.
Figura C11.F11: Pantalla para el Administrador con acceso a la actualización de Datos de Domicilio y de acceso para el conductor para
IN
IN
IN IN
IN
IN
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Domicilio Proceso: Actualización
de Domicilio del
Solicitante
Fecha: Septiembre/2011
Deja sin efecto los cambios hechos al Domicilio
Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta pcambios a los datos Personales, volviendo a un estado anterior válido.
: Pantalla para el Administrador con acceso a la actualización de Datos de Domicilio y de acceso para el conductor para
modificar sus datos.
B01
ADM
B01
B02
IN
IN
IN
IN
OUT
OUT
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 121
Actualización
P10
Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta pantalla.
: Pantalla para el Administrador con acceso a la actualización de Datos de Domicilio y de acceso para el conductor para
B02
ADM
ADM
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida
Figura C11.F12: Pantalla para el Administrador con acceso a la actualización de Datos de Domicilio y de acceso para el conductor para
OUT
OUT
OUT
OUT
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Carnet de Conducir Proceso: Visualización
de datos del carnet e
imagen.
Fecha: Septiembre/2011
: Pantalla para el Administrador con acceso a la actualización de Datos de Domicilio y de acceso para el conductor para
modificar sus datos.
OUT
OUT
OUT
OUT
OUT
OUT
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 122
Visualización
P11
: Pantalla para el Administrador con acceso a la actualización de Datos de Domicilio y de acceso para el conductor para
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida Grilla: Lista de todos las preguntas correspondiente a la actual categoría.P13: Abre la pantalla “P13”, ejecución manual de una infracción.B01 ADM: Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, para validar lopantalla. B02 ADM: Deja sin efecto los cambios a los Antecedentes, volviendo a un estado anterior válido.
Figura C11.F13: Pantalla para el Administrador con acceso a Antecedentes y para la aplicación de las infracciones manualm
OUT
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Antecedentes Proceso: Visualización
de infracciones para el
solicitante,
Actualización para
administrador.
Fecha: Septiembre/2011
: Lista de todos las preguntas correspondiente a la actual categoría. Abre la pantalla “P13”, ejecución manual de una infracción.
Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, para validar los cambios hechos en esta
Deja sin efecto los cambios a los Antecedentes, volviendo a un estado anterior válido.
: Pantalla para el Administrador con acceso a Antecedentes y para la aplicación de las infracciones manualm
acceso de lectura para el conductor.
P13
B01
ADM
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 123
Visualización
de infracciones para el
P12
s cambios hechos en esta
: Pantalla para el Administrador con acceso a Antecedentes y para la aplicación de las infracciones manualmente y
B02
ADM
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida B01 ADM: Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, ejecuta la infracción, sin esperar la aplicación automática del mismo. B02 ADM: Cierra el pop-up, sin hacer efectiva la ejecución de la infracción
Figura C11.F14: Pantalla para el Administrador para la aplicación de las infracciones manualmente.
B01 ADM
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Ejecución manual de
ejecución de
descuento de puntos
Proceso: Ejecutar el
descuento de puntos
manual
Fecha: Septiembre/2011
Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, ejecuta la infracción, sin esperar la
up, sin hacer efectiva la ejecución de la infracción, volviendo a la pantalla anterior.
: Pantalla para el Administrador para la aplicación de las infracciones manualmente.
OUT
OUT
OUT
OUT
B02 ADM
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 124
P13
Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, ejecuta la infracción, sin esperar la
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida B01: Ejecuta la acción iniciada, luego se cierra este popB02: Cancela la acción iniciada, luego se cierra este pop
B01
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Alerta de acción Proceso: Presionando
la opción “Si”, ejecuta
automáticamente la
acción elegida. Fecha: Septiembre/2011
la acción iniciada, luego se cierra este pop-up. Cancela la acción iniciada, luego se cierra este pop-up.
Figura C11.F15: Pantalla de Advertencia.
OUT
B02
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 125
Presionando
la opción “Si”, ejecuta P14
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida Grilla: Lista de todos las exámenes realizados o pedidos.P13: Abre la pantalla “P13”, ejecución manual de una infracción.B01: Confirma los turnos modificados B02: Deja sin efecto los cambios a los turnos modificadosM01: Genera nuevo Turno M02: Actualiza turno, si el mismo aún no fue realizado, luego solo es información de lectura.
Figura C11.F16: Pantalla de Turnos para el conductor. Consulta y generación de turnos a los distintos exámenes.
OUT
M02
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Turnos Proceso: Listado de
Turnos y resultado de
examen realizado.
Fecha: Septiembre/2011
: Lista de todos las exámenes realizados o pedidos. “P13”, ejecución manual de una infracción.
Deja sin efecto los cambios a los turnos modificados
Actualiza turno, si el mismo aún no fue realizado, luego solo es información de lectura.
Turnos para el conductor. Consulta y generación de turnos a los distintos exámenes.
OUT
OUT B01
B02 M01
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 126
Turnos y resultado de P15
Turnos para el conductor. Consulta y generación de turnos a los distintos exámenes.
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida Grilla: Lista de todos los vehículos asociados al conductor y el vinculo entre ellos
Figura C11.F17: Pantalla de acceso al
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Vehículos Proceso: Consulta de
lista de Vehículos y el
vínculo
correspondiente Fecha: Septiembre/2011
os vehículos asociados al conductor y el vinculo entre ellos.
: Pantalla de acceso al conductor para la visualización de los vehículos asociados a él.
OUT
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 127
Consulta de
hículos y el P16
OUT
Facultad de Ciencias Exactas
______________________________________________________________ Sistema: Sistema Emisor de
Carnet de Conducir
Autor: J.R.E.D.
Referencias:
OUT: Datos de Salida M02: La página vuelve a cargarse con la información a la que se refiere en la columna del botón verde “Leer Más”
Figura C11.F18: Pantalla Inicial después de logearse en el sistema,
Finalmente en esta última iteración se termina el diseño de las pantallas,
revisando nuevamente las clases, quedando un diagrama de clases definitivo.
Diagrama de Casos de Uso
Análisis
Iteración 1
Iteración 2
Iteración 3
Diseño
Iteración 4
Iteración 5
Iteración 6
Figura C11.
OUT
M01
M01
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz
Módulo: Inicio Proceso: Visualización
de noticias.
Fecha: Septiembre/2011
La página vuelve a cargarse con la información a la que se refiere en la columna del botón verde “Leer Más”
: Pantalla Inicial después de logearse en el sistema, pantalla informática.
Finalmente en esta última iteración se termina el diseño de las pantallas,
revisando nuevamente las clases, quedando un diagrama de clases definitivo.
Diagrama de Clases
Diagrama de Iteraciones
Diagrama de Diseño
.T1: Diagrama de Clases – Clases no Expandidas - Final
OUT OUT
M01
M01
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 128
Visualización
P17
Finalmente en esta última iteración se termina el diseño de las pantallas,
revisando nuevamente las clases, quedando un diagrama de clases definitivo.
Diagrama de
OUT
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 129
Capítulo VII
Conclusiones
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 130
El primer gran desafío, por el cual se decide usar esta metodología de
desarrollo, es usar la teoría proporcionada en dos materias dictadas en la Universidad
Nacional de Salta: Análisis de Sistemas de Información y Diseño de Sistemas de
Información, con la idea de aplicarlo finalmente en un sistema usando un caso de
estudio particular.
En un principio, el sistema era demasiado complejo, conteniendo subsistemas
tales como: la emisión del carnet de conducir, las infracciones, descuentos de puntos,
pagos de tickets, etc. El sistema no parecía tener un desarrollo con mucha exigencia,
pero después de consultar con un profesor de la facultad, este aconseja seguir
únicamente con el desarrollo en la emisión de los carnet de conducir, idea que
finalmente se adopta con una sensación que el desarrollo va a ser muy pobre. Pero
durante el desarrollo del presente sistema se evidencia iteración a iteración,
funcionalidades que no se habían previsto antes, o situaciones que en un principio no
cumplían el carácter de ser críticas. Aún así se incursiona sin muchos detalles en otros
subsistemas, solo para poder entender con más certeza el subsistema de emisión del
carnet de conducir.
Las lecturas, tomadas de las clases teóricas de las dos materias dictadas en la
facultad de exactas y sumando a ello, las ideas de Craig Larman plasmado en su libro
“UML y Patrones”, ayudaron a encontrar la punta del ovillo para comenzar a
desarrollar la idea propuesta por la metodología, con el desconocimiento de cómo
empezar el análisis y con la premisa de no entrar en detalles con los subsistemas que
no vamos a abordar se comienza con una iteración muy corta; una lista de funciones
de futuros supuestos casos de uso, que pareció ser una lista suficiente para empezar,
y luego de terminar la última iteración se observa notoriamente el incremento en el
tamaño de los diagramas de clases incluyendo sus propiedades y métodos,
demostrando así que esta metodología es un proceso iterativo e incremental.
Los diagramas de interacción tampoco fueron fáciles de iniciar, ya que en todo
momento uno se preguntaba sobre las clases participantes, luego de a poco salieron a
la luz nuevas clases o el desarrollo de más propiedades o métodos u organizar varias
clases como derivadas de una clase superior y definir los métodos en esta súper
clase, ya que en estos diagramas cobran vida los objetos interrelacionados con otros.
Una vez que se evidenció una “comunicación” entre objetos de distintas
clases, entonces se supo que era lo que se buscaba desde un principio, y desde ese
momento se empieza a desarrollar - corregir con más convicción, ya que en un
momento anterior el desarrollo era un vagar de ideas, correcciones y dudas. Los
diseños de las distintas pantallas también aportaron a la robustez de las clases al
conocer nuevas propiedades y métodos, mostrando finalmente lo que esperábamos
desde un principio, un diagrama de clases muy completo para el sistema.
En todas las iteraciones, las cuales incluyeron más de una fase, el desarrollo
de los casos de uso fué detallando las funciones genéricas y algunas iteraciones vistas
en un primer momento, el uso del Pencil ayudó a generar interfaces de cada pantalla
al disponer de herramientas sencillas y fáciles de implementar, mostrando así la
evolución del diseño en cada iteración en donde fue necesario. StartUML fué de gran
ayuda al momento de dibujar los casos de usos, pero no se pudo continuar para
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 131
graficar las clases y los diagramas, finalmente se usó Visual Studio para generar las
clases, sus relaciones y multiplicidades y los distintos diagramas de interacción.
De acuerdo a las conclusiones se puede remarcar varios puntos, que se
experimentaron desde que nació este proyecto de seminario.
1. Es importante no comprometer el análisis y el diseño a funcionalidades
que no se encuentren dentro del sistema objeto de estudio, en lo que se
refiere a recursos y tiempo que se dispone, de esa manera evitar
profundizar en temas que no tienen relación directa con el caso objeto
de estudio
2. Analizar la complejidad del software es importante, la importancia que
éste tiene para la organización y así definir en forma adecuada los
tiempos y recursos asignados.
3. La búsqueda de un software que ayude en el desarrollo también fue un
tema en el cual se invirtió tiempo, en las pruebas y en la utilización de
los mismos.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 132
Capítulo VIII
Bibliografía
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 133
[CLAR-UMLP2002]
C. Larman. 2002. “UML y Patrones: Una introducción al análisis y diseño
orientado a objetos y al proceso unificado – 2º Edición”. Pearson Educación.
[RJB-AW1999]
James Rumbaugh, Izar Jacobson, Grady Booch - El proceso unificado de
desarrollo de software (AddisonWesley, 1999)
[Cockburn-AW2001]
Cockburn A. - Agile Software Development(AddinsonWesley,2001)
[FULO-UO2006]
Aquilino Adolfo Juan Fuente, Juan Manuel Cueva Lovelle, Proyectos
informáticos -cuaderno didáctico nº49 de la colección de Ingeniería Informática
de la Universidad de Oviedo (Universidad de Oviedo, 2006)
[BG UML1996]
UML - Booch, Grady. 1996. Análisis y Diseño Orientado a Objetos. 2da edición.
Ed. Addison-Wesley / Díaz de Santos.
[ASI2006]
Adriana Binda, Ignacio Tuero y José Peralta, “Apuntes teóricos de la Cátedra de Análisis de Sistemas de Información” - Facultad de Ciencias Exactas - Universidad Nacional de Salta. Año 2004.
[DSI2007]
Adriana Binda, Ignacio Tuero y José Peralta, “Apuntes teóricos de la Cátedra de Diseño de Sistemas de Información” - Facultad de Ciencias Exactas - Universidad Nacional de Salta. Año 2005.
[PDF417WWW]
“Todo es electrónico”. PDF-417. Que es y para que sirve.
http://inza.wordpress.com/2006/09/14/pdf-417-que-es-y-para-que-sirve/
[Consulta: 21 de Junio 2011]
[SOFTPENCILWWW]
The OpenSource GUI Prototyping Tool www.pencil.evolus.vn/en-
US/Home.aspx [Consulta: 21 de Junio 2011]
[SOFTVisualStudio2010WWW]
Microsoft Visual Studio -
http://www.microsoftstore.com/store/msstore/en_US/pd/productID.216633300/c
ompare.true [Consulta: 25 de Noviembre 2011]
[ITE WWW0108]
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 134
Imagen – Iterative Development Image,
http://en.wikipedia.org/wiki/Image:Development-iterative.gif [Consulta: 5 de
mayo 2008]
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 135
Capítulo IX
Glosario
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 136
CORBA: Common Object Request Broker Architecture — arquitectura común
de intermediarios en peticiones a objetos.
DCOM: Distributed COM, conector OPC cliente a OPC Servidor.
OMT: Object-modeling technique.
OPC: OLE for Process Control, es un estándar de comunicación en el
campo del control y supervisión de procesos.
OO: Orientado a Objetos.
OOSE: Object Oriented Software Engineer.
UML: Unified Modeling Lenguaje.
GUI: Graphical User Interface – Interfaz gráfica para el usuario.
IDE: Integrated Development Environment.
USDP: Proceso Unificado de Desarrollo de Software,
GRASP: Acrónimo de General Responsability Assignment Software Patterns
(Patrones Generales de Software para Asignar Responsabilidades)
PRIMA: Es el precio del seguro que paga el asegurado al asegurador como
contraprestación del riesgo que asume éste y del compromiso que
es su consecuencia.
CONDUCTOR
PROFESIONAL:
Es aquella persona habilitada para conducir vehículos pesados y
transporte de personas.
MSDNAA Msdn Academic Alliance Software Center
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 137
ANEXO I
Marco Teórico
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 138
1 Marco Teórico
Un modelo de ciclo de vida de software es una vista de las actividades que se
llevan a cabo durante el desarrollo de este, e intenta determinar el orden de las etapas
involucradas y proporcionar unos criterios para avanzar de unas a otras, por tanto,
definir un ciclo de vida permite llevar un mayor control sobre las tareas, evitando que
estas se vayan eligiendo y realizando de manera desordenada, según parezca que
van surgiendo necesidades, que podrían ser puntuales y fácilmente evitables.
1.1 Uso del Proceso Unificado de Desarrollo
Debido al carácter relativamente investigador de este proyecto, y a la
necesidad de modificar los requisitos que surgirían según se fueran evaluando y
probando las distintas posibilidades con las que se cuenta para desarrollarlo, un
modelo pesado no se ajusta de manera adecuada. Sin embargo, un modelo
puramente ágil necesita de un equipo de desarrollo con experiencia para ser llevado a
cabo de manera satisfactoria, por lo que éste tampoco es el caso más adecuado para
su aplicación. Es por ello que se ha optado por un modelo que combina características
de ambas orientaciones, proporcionando un enfoque iterativo e incremental: el
Proceso Unificado de Desarrollo propuesto por Rumbaugh, Booch y Jacobson. [RJB-
AW1999]
1.1.1 Características del Proceso Unificado de Desarrollo
Al igual que con cualquier otro modelo de desarrollo, del Proceso Unificado
también se pueden destacar ciertas características: [RJB-AW1999]
Iterativo e incremental: El Proceso Unificado es un marco de desarrollo
compuesto de cuatro fases:
Inicio
Elaboración
Construcción
Transición
Cada una de ellas es, a su vez, dividida en una serie de iteraciones que
ofrecen como resultado un incremento del producto desarrollado, que añade o
mejora las funcionalidades del sistema en desarrollo. Es decir, un “incremento”
no implica necesariamente una ampliación de dicho sistema.
Durante cada una de estas iteraciones se realizarán a su vez las
actividades definidas en el ciclo de vida clásico: requisitos, análisis, diseño,
implementación, prueba e implantación. Aunque todas las iteraciones suelen
incluir trabajo en casi todas estas actividades, el grado de esfuerzo dentro de
cada una de ellas varía a lo largo del proyecto. Por ejemplo, en la fase de inicio
se centrarán más en la definición de requisitos y en el análisis, y durante la de
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 139
construcción quedarán relegadas en favor de la implementación y las pruebas.
Si una iteración cumple sus metas, publicando una nueva versión del producto
que implemente ciertos casos de uso, el desarrollo continúa con la siguiente.
Cuando no las cumple, los desarrolladores deben revisar sus decisiones
previas y probar un nuevo enfoque.
Dirigido por los casos de uso: Un sistema software se crea para servir a sus
usuarios por lo que, para construir un sistema exitoso, se debe conocer qué es
lo que quieren y necesitan. El término “usuario” no se refiere solamente a los
usuarios humanos sino también a otros sistemas, es decir, representa a algo o
alguien que interactúa con el sistema a desarrollar.
En el Proceso Unificado, los casos de uso se utilizan para capturar los
requisitos funcionales y para definir los objetivos de las iteraciones. En cada
una, los desarrolladores identifican y especifican los casos de uso relevantes,
crean el diseño usando la arquitectura como guía, implementan el diseño en
componentes y verifican que los componentes satisfacen los casos de uso.
Centrado en la arquitectura: El concepto de arquitectura del software
involucra los aspectos estáticos y dinámicos más significativos del sistema, y
actúa como vista del diseño, dando una perspectiva completa y describiendo
los elementos más importantes. La arquitectura surge de los propios casos de
uso, sin embargo, también está influenciada por muchos otros factores, como
la plataforma en la que se ejecutará, el uso de estándares, la existencia de
sistemas heredados (aunque éste no sea el caso que nos ocupa) o los
requisitos no funcionales.
Puesto que la arquitectura y los casos de uso están relacionados, por
una parte, los casos de uso deben, cuando son realizados, acomodarse en la
arquitectura, y ésta debe ser lo bastante flexible para realizar todos los casos
de uso, hoy y en el futuro. De palabras de los propios creados del Proceso
Unificado, es un problema semejante al del “huevo y la gallina”. En la realidad,
arquitectura y casos de uso deben evolucionar en paralelo.
Enfocado en los riesgos: Para disminuir la posibilidad de fallo en las
iteraciones o incluso la de cancelación del proyecto, se deben llevar a cabo
sucesivos análisis de riesgos durante todo el desarrollo. Por supuesto, los
riesgos principales deben ser identificados en una etapa temprana del ciclo de
vida, y además, los resultados de cada iteración deben seleccionarse en un
orden que asegure que estos son considerados primero.
1.1.2 Vida del Proceso Unificado de Desarrollo
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen
la vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del
producto, que no sólo satisface ciertos casos de uso, sino que está lista para ser
entregada y puesta en producción. En caso de que fuese necesario publicar otra
versión, deberían repetirse los mismos pasos a lo largo de otro ciclo. Como se ha
comentado en el apartado anterior, cada ciclo se compone de varias fases, y dentro de
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 140
cada una de ellas, los directores o los desarrolladores pueden descomponer
adicionalmente el trabajo en iteraciones, con sus incrementos resultantes. Cada fase
termina con un hito, determinado por la disponibilidad de un conjunto de artefactos,
modelos o documentos.
Las iteraciones de cada fase se desarrollan a través de las actividades de
identificación de requisitos, análisis, diseño, implementación, pruebas e integración,
como lo muestra en el siguiente grafico.
Figura C2.F1: EL Desarrollo Iterativo de acuerdo a las distintas etapas e iteraciones.
[IID WWW0108]
Fase de Inicio: Suele ser la fase más corta del desarrollo, y no debería alargarse
demasiado en el tiempo. En caso contrario, podríamos encontrarnos en una
situación de excesiva especificación inicial, yendo en contra del enfoque
relativamente ágil del Proceso Unificado.
En esta fase se realizan las siguientes tareas:
Desarrollar una descripción del producto final y presentar el análisis de
negocio.
Realizar una identificación inicial de riesgos.
Establecer las principales funciones del sistema para los usuarios más
importantes, la arquitectura a grandes rasgos y un plan de proyecto.
La fase de inicio termina con el hito de los objetivos del desarrollo.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 141
Fase de Elaboración: Durante esta fase deberán capturarse la mayoría de
requisitos del sistema, aunque los objetivos principales son tratar los riesgos ya
identificados y establecer y validar la base de la arquitectura del sistema. Esta
base se realizará a través de varias iteraciones, y servirá de punto de partida para
la fase de construcción.
La fase de elaboración termina, por tanto, al alcanzar el hito de la
arquitectura del sistema.
Fase de Construcción: Es la fase más larga del proyecto, y completa la
implementación del sistema tomando como base la arquitectura obtenida durante
la fase de elaboración. A partir de ella, las distintas funcionalidades son incluidas
en distintas iteraciones, al final de cada una de las cuales se obtendrá una nueva
versión ejecutable del producto.
Por tanto, esta fase concluye con el hito de obtención de una funcionalidad
completa, que capacite al producto para funcionar en un entorno de producción.
Fase de Transición: En la fase final del proyecto se lleva a cabo el despliegue del
producto en el entorno de los usuarios, lo que incluye la formación de éstos. En lo
relativo a la evolución del propio producto software:
Gracias a las opiniones obtenidas de versiones preliminares, evoluciona
desde la fase beta a una versión final.
Se resuelven incidencias en la implantación e integración, y si existen, se
clasifican aquellas que podrían justificar una nueva versión del producto.
Esta fase concluye con el hito de publicación del producto.
1.1.3 Documentación del Proceso Unificado de Desarrollo
Para plasmar de manera clara y ordenada el proceso de desarrollo del
proyecto, esta documentación se dividirá en una sección para cada fase del modelo de
ciclo de vida, mostrando los datos de los que se partía en cada una de ellas, las tareas
realizadas y los productos obtenidos finalmente.[FULO-UO2006]
También por claridad, se evitará explicar una a una las iteraciones llevadas a
cabo, y en su lugar nos centraremos en los trabajos realizados en cada actividad del
proceso.
1.2 UML
1.2.1 Unified Modeling Language (UML)
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 142
UML es un lenguaje para especificar, construir, visualizar y documentar los
artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una
información que es utilizada o producida mediante un proceso de desarrollo de
software.[BG UML1996]
Este lenguaje se quiere convertir en un modelo estándar con el que sea posible
modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin
embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende
definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado.
Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí
definen procesos concretos. En UML los procesos de desarrollo son diferentes según
los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una
aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a
gestión, por poner un ejemplo.
Las diferencias son muy marcadas y afectan a todas las fases del proceso. El
método del UML recomienda utilizar los procesos que otras metodologías tienen
definidos.
A partir del año 1994, Grady Booch (precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se añade al grupo.
Como objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:
Ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).
Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
Manejar los problemas típicos de los sistemas complejos de misión crítica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la OO.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 143
1.2.1.1 Modelado de objeto
En la especificación del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos, posiblemente desde distintos puntos de vista.
Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo. Es una herramienta de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.
Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta.
Los modelos además, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:
Posibilitan enseñar al cliente una posible aproximación de lo que será el producto final.
Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.
Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado.
UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 144
del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.
1.2.2 Artefactos para el Desarrollo de Proyectos
Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software. Los artefactos de UML se especifican en forma de diagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar.
Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema:
Diagramas de Implementación. Diagramas de Comportamiento o Interacción. Diagramas de Casos de uso. Diagramas de Clases.
Diagramas de Implementación: Se derivan de los diagramas de proceso y módulos de la metodología de Booch, aunque presentan algunas modificaciones. Los diagramas de implementación muestran los aspectos físicos del sistema. Incluyen la estructura del código fuente y la implementación, en tiempo de implementación. Existen dos tipos:
Diagramas de componentes Diagrama de plataformas o despliegue
Diagramas de componentes: Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de código fuente, binario y ejecutable. Un componente es un fragmento de código software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilación.
Diagrama de plataformas o despliegue: Muestran la configuración de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecución y los objetos que existen en tiempo de ejecución. En este tipo de diagramas intervienen nodos, asociaciones de comunicación, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto físico en tiempo de ejecución, es decir una máquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formada por otros componentes.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 145
1.2.2.1 Diagramas de Interacción o Comportamiento
Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:
Diagramas de secuencia. Diagramas de colaboración. Diagramas de estado. Diagramas de actividad. Diagramas de secuencia.
Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.
En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se producen en el tiempo: simples, síncronos, y asíncronos. Los diagramas de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama.
Diagramas de colaboración: Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.
Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.
Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.
Los diagramas de interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, timeout y asíncronos. Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 146
Diagramas de actividad: Son similares a los diagramas de flujo de otras metodologías OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier otra metodología OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.
Diagramas de estado: Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisfacen una condición, desarrolla alguna acción o se encuentra esperando un evento.
Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición. Como en todas las metodologías OO se envían mensajes, en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destino.
1.2.2.2 Diagramas de Casos de Usos
Los casos de usos son una secuencia de transacciones que serán desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:
Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 147
1.2.2.3 Diagramas de Clases
Los diagramas de clases representan un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos.
Algunos de los elementos que se pueden clasificar como estáticos son los siguientes:
Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un único paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitiéndose que un paquete contenga otro paquete.
Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, métodos, relaciones y significado. En UML una clase es una implementación de un tipo. Los componentes de una clase son: Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos. Operación. También conocido como método, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza.
Las clases pueden tener varios parámetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrán definidos según sus parámetros formales. Las plantillas pueden tener especificados los valores reales para los parámetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podría aparecer su plantilla.
Relacionando con las clases nos encontramos con el término utilidad, que se corresponde con una agrupación de variables y procedimientos globales en forma de declaración de clase, también puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaración de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programación.
Metaclase: Es una clase cuyas instancias son clases. Sirven como depósito para mantener las variables de clase y proporcionan operaciones (método de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos).
Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementación. Un tipo establece una especificación de comportamiento para las clases.
Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo.
Relación entre clases: Las clases se relacionan entre sí de distintas formas, que marcan los tipos de relaciones existentes:
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 148
Asociación: Es una relación que describe un conjunto de vínculos entre clases. Pueden ser binarias o n-arias, según se implican a dos clases o más. Las relaciones de asociación vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociación (existen otros tipos de roles según la relación a la que identifiquen). Indican la información más importante de las asociaciones. Es posible indicar el número de instancias de una clase que participan en una relación mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociación permiten especificar qué objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociación que determina los valores que indican cuales son los valores que se asociarán.
Una asociación se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociación. Existe una forma especial de asociación, la agregación, que especifica una relación entre las clases donde el llamado "agregado" indica él todo y el "componente" es una parte del mismo.
Composición: Es un tipo de agregación donde la relación de posesión es tan fuerte como para marcar otro tipo de relación. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composición, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos.
Generalización: Cuando se establece una relación de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber más de una clase que se comporte como subclase.
Dependencia: Una relación de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente.
1.2.3 Relación de Refinamiento
Es una relación entre dos elementos donde uno de ellos especifica de forma completa al otro que ya ha sido especificado con cierto detalle. Además de los conceptos extraídos de métodos anteriores, se han añadido otros nuevos que vienen a suplir carencias antiguas de la metodología de modelado. Estos nuevos conceptos son los siguientes:
Definición de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensión del modelo.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 149
1.2.4 El Proceso de Desarrollo
UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas. UML es un método independiente del proceso. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas.
1.3 Patrones GRASP: Patrones de Principios Generales para Asignar Responsabilidades [CLAR-UMLP2002]
GRASP es un acrónimo de General Responsability Assignment Software
Patterns (Patrones Generales de Software para Asignar Responsabilidades).
Después de identificar los requisitos y de crear un modelo de dominio, hay que
añadir métodos a las clases software y definir el paso de mensajes entre objetos para
así satisfacer los requisitos. La decisión de que métodos, donde colocarlos y como
deberían interactuar los objetos es muy importante. Eso es lo esencial de lo que
entendemos por “desarrollar un sistema orientado a objetos”.
Los patrones GRASP constituyen un apoyo para la enseñanza que ayuda a
uno a entender el diseño de objetos esencial, y aplica el razonamiento para el diseño
de una forma sistemática, racional y explicable. Se basa en los patrones de asignación
de responsabilidades.
Las responsabilidades están relacionadas con las obligaciones de un objeto en
cuanto a su comportamiento. Pueden ser de dos tipos: responsabilidad de conocer
(por ejemplo conocer los datos encapsulados o conocer los objetos relacionados) o
responsabilidad de hacer (por ejemplo crear un objeto o controlar y coordinar
actividades entre otros objetos).
Dichas responsabilidades se asignan a las clases de objetos durante el diseño
de objetos. Las responsabilidades “de conocer” a menudo se pueden inferir a partir del
modelo del dominio, debido a los atributos y asociaciones que describe.
Cabe aclarar que una responsabilidad no es lo mismo que un método, pero los
métodos se implementan para llevar a cabo las responsabilidades. O sea, las
responsabilidades se implementan usando métodos que actúan solos o colaboran con
otros métodos u objetos.
En los diagramas de interacción se reflejarán las elecciones en cuanto a la
asignación de responsabilidades a los objetos. Esta asignación de responsabilidades
se verá reflejada en los mensajes que se envían las diferentes clases de objetos.
¿Qué son los patrones GRASP?
Describen los principios fundamentales del diseño de objetos y la asignación de responsabilidades, expresados como patrones
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 150
Los desarrolladores acumulan un repertorio tanto de principios generales como
de soluciones basadas en aplicar ciertos estilos que les guían en la creación de
software. Estos principios y estilos pueden codificarse en un formato estructurado que
describa el problema y la solución al mismo, llamado patrón. Entonces, un patrón es
un par problema/solución con nombre. Este par se puede aplicar en nuevos contextos,
con consejos acerca de cómo aplicarlos en situaciones nuevas y discusiones sobre
sus compromisos. Los patrones pretenden codificar conocimientos, estilos y principios
existentes y que se han probado que son válidos.
Los cinco patrones GRASP más importantes son:
Experto en información
Creador
Alta cohesión
Bajo acoplamiento
Controlador
Existen otros patrones de diseño, pero en este seminario me concentraré en
estos cinco, ya que se refieren a cuestiones básicas, comunes y a aspectos
fundamentales de diseño; que es necesario que cualquier desarrollador domine.
Experto en información: El problema que trata este patrón es: ¿que principio
general usar para asignar responsabilidades a objetos? La solución que brinda
es asignar una responsabilidad al experto en información (aquella clase que
tiene la información necesaria para realizar la responsabilidad).
Al desarrollar un sistema, podríamos encontrar muchas clases software
y podría ser necesario que se realicen cientos o miles de responsabilidades.
Durante el diseño de objetos, cuando se refinan las interacciones entre los
objetos, se toma la decisión de asignar responsabilidades a las clases
software. Si esto se hace de manera adecuada, el sistema será más fácil de
entender, mantener y ampliar, y ayudará a la reutilización de componentes.
El patrón Experto en Información tiene una analogía con el mundo real
ya que lo que normalmente se hace es otorgarles responsabilidades a los
individuos que cuentan con la información necesaria para realizar la tarea. Y
del mismo modo en que los objetos colaboran porque la información está
dispersa, así pasa con las personas.
En algunas ocasiones este patrón no es deseable, normalmente por
cuestiones de cohesión y de acoplamiento, principios que ya veremos.
Entre los beneficios que nos brinda este patrón tenemos:
Se mantiene el encapsulamiento de la información, ya que los
objetos usan su propia información para llevar a cabo las tareas.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 151
Normalmente esto lleva a un bajo acoplamiento, lo que da lugar
a sistemas más robustos y fáciles de mantener.
Se distribuye el comportamiento entre las clases que contienen
la información necesaria, por lo que se estimula las definiciones
de clases más cohesivas que son más fáciles de entender y de
mantener.
Creador: El problema que trata este patrón es: ¿quién debería ser el responsable de la creación de una nueva instancia de alguna clase? La solución que brinda es asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple uno o más de los siguientes casos:
B agrega objetos de A
B contiene objetos de A
B registra instancias de objetos de A
B utiliza más estrechamente objetos de A
B tiene los datos de inicialización que se pasarían a un objeto de A
cuando se creado (B es un Experto con respecto a la creación de A).
Si se puede aplicar más de una opción, hay que inclinarse por una clase
B que agregue o contenga la clase A.
La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos, por lo que es extremadamente útil contar con un principio general para la asignación de responsabilidades de creación. Si se asignan bien, esto ayudará a obtener un bajo acoplamiento, mayor claridad, encapsulamiento y reutilización.
Entre los beneficios que nos brinda este patrón es que soporta bajo acoplamiento, lo que implica menos dependencias de mantenimiento y mayores oportunidades para reutilizar.
Bajo Acoplamiento: El problema que trata este patrón es: ¿cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización? La solución que brinda es asignar una responsabilidad de manera que el acoplamiento permanezca bajo.
El acoplamiento es la fuerza con que un elemento está conectado a,
tiene conocimiento de, confía en, otros elementos. Un elemento con bajo
acoplamiento no depende demasiado de otros elementos.
Una clase con un alto acoplamiento confía demasiado en otras clases.
Esto no es deseable porque se tienen los siguientes problemas:
Los cambios en las clases relacionadas fuerzan cambios locales.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 152
Son difíciles de entender de manera aislada.
Son difíciles de reutilizar, ya que su uso requiere la presencia adicional de las clases de las que depende.
En la práctica, el nivel de acoplamiento no se puede considerar de
manera aislada a otros principios como el Experto o Alta Cohesión. Sin
embargo, es un factor a tener en cuenta para mejorar el diseño.
El Bajo Acoplamiento es deseado porque soporta el diseño de clases
que son más independientes, lo que reduce el impacto del cambio.
Una subclase está fuertemente acoplada a su superclase. Entonces,
deberíamos estudiar cuidadosamente la decisión de derivar a partir de una
superclase.
Es importante saber que no existe una medida absoluta de cuando el
acoplamiento es demasiado alto. Aquí interviene el criterio y la experiencia del
desarrollador para medir el grado de acoplamiento actual, y evaluar si
aumentarlo le causará problema.
El caso extremo de Bajo Acoplamiento es cuando no existe
acoplamiento entre las clases. Esto tampoco es deseable porque producirá un
diseño pobre que dará lugar a unos pocos objetos inconexos, saturados, y con
actividad compleja que hacen todo el tratamiento; y con muchos objetos muy
pasivos, sin acoplamiento que actúan como simples repositorios de datos.
Justamente, la idea de diseñar orientado a objetos es que los mismos
interactúen mediante el pasaje de mensajes para cumplir los requisitos.
Entonces, lo deseable es un grado moderado de acoplamiento entre las
clases para crear un sistema orientado a objetos en el que las tareas se lleven
a cabo mediante la colaboración de los objetos conectados.
Entre los beneficios que nos brinda este patrón tenemos:
No afectan los cambios en otros componentes.
Fácil de entender de manera aislada.
Es conveniente para reutilizar.
Alta Cohesión: El problema que trata este patrón es: ¿cómo mantener la complejidad manejable? La solución que propone es asignar una responsabilidad de manera que la cohesión permanezca alta.
La cohesión es una medida de la fuerza con la que se relacionan y del
grado de focalización de las responsabilidades de un elemento. Puede definirse
también como: la fuerza con la que están unidas las sentencias de un módulo
respecto a la función que debe realizar. [DSI2007]
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 153
Un elemento con responsabilidades altamente relacionadas que no
hace una gran cantidad de trabajo tiene una alta cohesión. Un elemento con
baja cohesión hace muchas cosas no relacionadas.
Una clase con baja cohesión hace muchas cosas no relacionadas, o
hace demasiado trabajo. Esto no es deseable porque una clase así:
Es difícil de entender.
Es difícil de reutilizar.
Es difícil de mantener.
Es delicada, constantemente afectada por los cambios.
Los elementos con baja cohesión generalmente aparecen porque se les
ha asignado responsabilidades que deberían haberse delegado a otros
elementos.
En la práctica, el nivel de cohesión no se puede considerar de manera
aislada a otras responsabilidades y otros principios como los patrones Experto
y Bajo Acoplamiento.
Este patrón es un principio a tener en mente durante todas las
decisiones de diseño; es un objetivo subyacente a tener en cuenta.
Grady Booch establece que existe la alta cohesión funcional cuando los
elementos de un componente (como por ejemplo una clase): “trabajan todos
juntos para proporcionar algún comportamiento bien delimitado”. [BG UML1996]
Como regla empírica, una clase con alta cohesión tiene un número
relativamente pequeño de métodos, con funcionalidad relacionada, y no realiza
mucho trabajo. Colabora con otros objetos para compartir el esfuerzo si la tarea
es extensa.
Una clase con alta cohesión es ventajosa porque es relativamente fácil
de mantener, entender y reutilizar. Al tener un alto grado de funcionalidad
relacionada, combinada en un número pequeño de operaciones, se simplifica el
mantenimiento y las mejoras, y aumenta el potencial de reutilización.
El patrón Alta Cohesión tiene una analogía con el mundo real. Si una
persona tiene demasiadas responsabilidades no relacionadas, entonces la
persona no es efectiva.
Otro principio que está muy relacionado con el acoplamiento y la
cohesión es promover el diseño modular. Según Grady Booch, “La modularidad
es la propiedad de un sistema que se ha descompuesto en un conjunto de
módulos cohesivos y débilmente acoplados” [BG UML1996]
Entonces, la idea es fomentar el diseño modular creando métodos y
clases con alta cohesión. Al nivel básico de objetos, la modularidad se alcanza
diseñando cada método con un único objetivo, y agrupando un conjunto de
aspectos relacionados en una clase.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 154
Entre los beneficios que nos brinda este patrón tenemos:
Se incrementa la claridad y facilita la comprensión del diseño.
Se simplifica el mantenimiento.
Se soporta a menudo bajo acoplamiento.
El grano fino de funcionalidad altamente relacionada incrementa la reutilización porque una clase cohesiva se puede usar con un propósito muy específico.
Controlador: El problema que trata este patrón es: ¿quién debe ser responsable de gestionar un evento de entrada al sistema? La solución que brinda es asignar dicha responsabilidad a una clase que representa una de las siguientes opciones:
Representa el sistema global, dispositivo o subsistema (controlador
de fachada).
Representa un escenario de caso de uso en el que tiene lugar el
evento del sistema llamado normalmente <NombreCU> Manejador,
<NombreCU> Coordinador, <NombreCU> Sesión (controlador de
sesión o del caso de uso).
Según Larman la idea es usar la misma clase de controlador para todos
los eventos del sistema en el mismo escenario de caso de uso.
Un evento del sistema de entrada es un evento generado por un actor
externo. Se asocian con operaciones del sistema (como respuesta a los
eventos del sistema), tal como se relacionan los mensajes y los métodos.
Un Controlador es un objeto que no pertenece a la interfaz de usuario,
responsable de recibir o manejar en evento del sistema. Un controlador define
un método para la operación del sistema.
Durante el análisis, las operaciones del sistema pueden asignarse a la
clase Sistema, para indicar que se trata de operaciones del sistema. Pero, esto
no significa que una clase software llamada Sistema las lleve a cabo durante el
diseño. De hecho, durante el diseño, se asigna la responsabilidad de las
operaciones del sistema a una clase Controlador.
La clase “Ventana” o “Frame” no deberían abordar las tareas
relacionadas con los eventos del sistema. Solo deben recibirlos y delegarlos al
controlador.
Durante el diseño, se asignan a una o más clases controlador las
operaciones del sistema identificadas durante el análisis del comportamiento
del sistema. Normalmente, este controlador debería delegar a otros objetos el
trabajo que se necesita hacer; coordina o controla una actividad. No realiza
mucho trabajo por si mismo.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 155
Entre los beneficios que nos brinda este patrón tenemos:
Aumenta el potencial para reutilizar y las interfaces conectables: Asegura que la lógica de la aplicación no la maneje la capa de interfaz. Técnicamente, las responsabilidades de un controlador podría manejarla la interfaz, pero esto implica que el código del programa, y la lógica relacionada con la realización de la lógica del la aplicación esté embebida en los objetos ventana o interfaz. Este tipo de diseño reduce la oportunidad de reutilizar la lógica porque está ligada a una interfaz particular que raramente es aplicable a otras aplicaciones. Al delegar la responsabilidad de una operación del sistema a un controlador, se ayuda a la reutilización de la lógica en futuras aplicaciones.
Razonamiento sobre el estado de los casos de uso: a veces necesitamos asegurar que las operaciones del sistema tienen lugar en una secuencia válida, o ser capaces de razonar sobre el estado actual de la actividad y operaciones del caso de uso que esta ejecutándose.
Seminario de Sistemas Facultad de Ciencias Exactas
2011
______________________________________________________________
C.U. Joel Rodrigo Escalera Díaz Página 156
.
Impreso el día 06 de Agosto de 2014