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”


2011

______________________________________________________________


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


2011

______________________________________________________________


Dedicatoria

Ima Susy


2011

______________________________________________________________


Agradecimientos

A papá y a Iris quienes me ayudaron durante este ciclo.


2011

______________________________________________________________


Í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


2011

______________________________________________________________


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


2011

______________________________________________________________


Introducción

El sistema objeto a desarrollar, es de emisión de un carnet de conducir electrónico en las diferentes categorías existentes.


2011

______________________________________________________________


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.


2011

______________________________________________________________


Capítulo I

Sistema objeto de Estudio

“Emisión de carnet de conducir electrónicos”

Funcionalidades del Sistema

Puntuaciones

1 Funcionalidades del Sistema


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


Capítulo IV

Estudio de Factibilidad


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


Figura C6.F3: Folleto Informativo Paginas 1-2


2011

______________________________________________________________


Figura C6.F4: Folleto Informativo Paginas 3-4


2011

______________________________________________________________


Figura C6.F5: Folleto Informativo Paginas 5


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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



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



2011

______________________________________________________________


10 años sin descuento $500,00

Emisión y envío ($350,00)

Sub total 1 Persona $150,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 en 2º Carnet 500

Costo Carnet nuevamente $50


Costo 2º Color $1120


Costo Carnet $50,00

Emisión y envío $35,00

2º Color $1.120,00

Sub total 1 Persona $1.205,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 en 3º Carnet 100

Costo Carnet nuevamente $50


Costo 3º Color $2800


Costo Carnet $50,00

Emisión y envío $35,00


2011

______________________________________________________________


3º Color $2.800,00

Sub total 1 Persona $2.885,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.


2011

______________________________________________________________


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


2011

______________________________________________________________


Multas en el sistema Manual

Personas 1000

Multas por año encontradas 1

Multa Modelo $100

Cobrable 100%


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%


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.


2011

______________________________________________________________


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



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


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


Capítulo V

Análisis


2011

______________________________________________________________


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


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


Post condiciones Examen Teórico Terminado



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.


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



Post condiciones: Examen Practico Terminado




teórico.


2011

______________________________________________________________




04 Iniciar generación de Examen Practico

05 Asociar preguntas de Examen Practico a realizar a

la solicitud



Caso de Excepción





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



Post condiciones:

Examen Médico Terminado




teórico.



04 Iniciar generación de Examen Médico

05 Asociar preguntas de Examen Médico a realizar a la

solicitud




2011

______________________________________________________________


Caso de Excepción





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.


Post condiciones: Ticket a Pagar Calculado



01 Iniciar generación de tickets a pagar


03 Mostrar Inicio de generación de tickets

04 Generar transacción


Caso de Excepción





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


2011

______________________________________________________________


Post condiciones: Examen Teórico realizado.



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


Caso de Excepción


02.1 Informar DNI ingresado no válido


Caso de Excepción



válidos


Figura C8.F8: Cargar resultado examen de practicas


2011

______________________________________________________________


CU: 07 Cargar resultado examen de practicas

Actor: Examinador Práctico.

Evento Inicial:

Precondiciones: Examen ya cargado, Usuario registrado, solicitud inicializada






03 Seleccionar opción Examen Practico


05 Mostrar cantidad de puntos a evaluar


07 Mostrar Fecha y hora de inicio de examen.

08 Mostrar un punto a evaluar



mostradas.

11 Repetir los pasos 8-10 hasta terminar todos los puntos a evaluar



14 Mostrar Fecha y hora final de examen.



Caso de Excepción




Caso de Excepción




2011

______________________________________________________________


válidos


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






03 Mostrar opción Examen Médico-Clínico.


05 Mostrar cantidad de puntos a evaluar


07 Mostrar Fecha y hora de inicio de examen.

08 Mostrar un punto a evaluar



mostradas.

11 Repetir los pasos 8-10 hasta terminar todos los puntos a evaluar



14 Mostrar Fecha y hora final de examen.



Caso de Excepción



2011

______________________________________________________________




Caso de Excepción



válidos


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:


Post condiciones: Fotografía cargado en el sistema





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


Caso de Excepción




Figura C8.F10: Caso de Uso: Cargar fotografía en el sistema


2011

______________________________________________________________


CU: 10 Cargar huella digital en el sistema

Actor: Conductor

Evento Inicial:


Post condiciones: Huella y firma digital cargada en el sistema





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


Caso de Excepción




Caso de Excepción


07.1 Informar huella digital no válida


Figura C8.F11: Caso de Uso: Cargar huella digital en el sistema


2011

______________________________________________________________


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



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


Caso de Excepción





2011

______________________________________________________________


Caso de Excepción

11 Validar cuestionario completado


válidos


Caso de Excepción

13 Validar posibles respuestas completadas


válidos


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



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


Caso de Excepción

05 Validar Código ingresado


2011

______________________________________________________________


02.1 Informar Código ingresado no válido


Figura C8.F13: Caso de Uso: Ingresar pagos efectuados en el sistema

CU: 13 Ingresar reglamento de los puntos en el sistema


Evento Inicial:

Precondiciones: Logeado en Sistema

Post condiciones: Reglamento cargado



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


Caso de Excepción

07 Validar nuevo reglamento


válidos


Figura C8.F14: Caso de Uso: Ingresar reglamento de los puntos en el sistema


2011

______________________________________________________________


CU: 14 Ingresar reglamento de las condiciones para la solicitud de carnet de conducir en el

sistema


Evento Inicial:


Post condiciones: Reglamento para condiciones de solicitud cargado



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



Caso de Excepción


08.1 Informar ítems vacios o ingresados pero no

válidos


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



2011

______________________________________________________________


Evento Inicial:


Post condiciones: Reglamento para las multas cargado



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





Caso de Excepción



válidos


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


Evento Inicial:


Post condiciones: Centros Médicos cargado en el sistema


2011

______________________________________________________________




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


Caso de Excepción

09 Validar centro médico ingresado


válidos


Figura C8.F17: Caso de Uso: Ingresar centros médicos en el sistema

CU: 17 Ingresar médicos en el sistema


Evento Inicial:

Precondiciones Logeado en Sistema

Post condiciones: Médicos cargado en el sistema




2011

______________________________________________________________


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


Caso de Excepción



válidos


Figura C8.F18: Caso de Uso: Ingresar médicos en el sistema

CU: 18 Ingresar examinadores en el sistema


Evento Inicial:


Post condiciones: Examinadores cargado en el sistema



01 Seleccionar ingreso de examinadores en el

sistema

02 Mostrar pantalla de ingreso de examinadores


2011

______________________________________________________________


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


Caso de Excepción

10 Validar datos del examinador


válidos


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



01 Seleccionar consulta de estado de solicitud del

carnet de conducir

02 Mostrar pantalla de consulta de solicitud

03 Iniciar consulta


2011

______________________________________________________________


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


Figura C8.F20: Caso de Uso: Consultar estado de solicitud del carnet de conducir

CU: 20 Ingresar condiciones de recupero de puntos.


Evento Inicial:


Post condiciones: Condiciones de recupero de puntos cargado en el 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


Caso de Excepción


2011

______________________________________________________________




válidos


Figura C8.F21: Caso de Uso: Ingresar condiciones de recupero de puntos.

CU: 21 Ingresar condiciones de recupero niveles de carnet de conducir.


Evento Inicial:


Post condiciones: Condiciones de recupero de niveles de carnet de conducir cargado en el 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


09 Guardar condición

10 Realizar los pasos 03-09 hasta terminar de cargar las condiciones.


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



2011

______________________________________________________________



válidos


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:


Post condiciones: Nueva infracción cargado en el 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



Caso de Excepción



válidos


Figura C8.F23: Caso de Uso: Ingresar nueva infracción en el sistema


2011

______________________________________________________________


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



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


Caso de Excepción


04.1 Informar selección de solicitud no realizada


Figura C8.F24: Caso de Uso: Ingresar solicitud de recupero de puntos


2011

______________________________________________________________


CU: 24 Ingresar solicitud de recupero de nivel de categoría

Actor: Usuario

Evento Inicial:


Post condiciones: Nueva solicitud de recupero de nivel de categoría cargado en el 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


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


Caso de Excepción


04.1 Informar selección de solicitud no realizada


Figura C8.F25: Caso de Uso: Ingresar solicitud de recupero de nivel de categoría

6


2011

______________________________________________________________


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.


2011

______________________________________________________________


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 Clases


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



______________________________________________________________ Iteración 3: Corrección de Casos

1. Corrección de Casos de Uso


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


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


Figura C9.F1: Diagrama de Clases correspondiente al comienzo de la iteración 3.

______________________________________________________________


ión de cada clases,

es necesario



2011

______________________________________________________________


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.


2011

______________________________________________________________


1.2.1 Casos de Uso resultantes en esta iteración

CU: 01 El solicitante ingresa solicitud online del carnet de conducir


Evento Inicial: Se solicita inicio de trámites en el Sistema


Post condiciones: Solicitud iniciada. Primera etapa del trámite terminado



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.


práctico


examen práctico


disponibles.


médico


examen médico


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.


2011

______________________________________________________________


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.


Caso de Excepción




Caso de Excepción

13 Validar ítems seleccionados


válidos


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.





03 Seleccionar opción carga de fotografía

04 Mostrar inicio de captura de fotografía


2011

______________________________________________________________


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


15 Guardar huella dactilar

16 Actualizar datos personales de otro sistema

de datos personales

17 Actualizar estado de datos personales


Caso de Excepción




Caso de Excepción

08 Validar Fotografía ingresada

08.1 Informar fotografía ingresada no válido


Caso de Excepción


14.1 Informar huella digital no válida


Figura C9.F3: Caso de Uso: Ingresar solicitud online de solicitud del carnet de conducir


2011

______________________________________________________________


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



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.


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



12 Realizar los pasos 02-11 hasta terminar de cargar los reglamentos a la infracción


Caso de Excepción



válidos


Figura C9.F4: Caso de Uso: Ingresar reglamento de los puntos en el sistema


2011

______________________________________________________________


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



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)


07 Guardar ubicación geográfica (GPS)

08 Guardar ID usuario Logeado


10 Guardar infracció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




Caso de Excepción




2011

______________________________________________________________


válidos


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.



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.


Datos relacionados al domicilio que figura en

el DNI.

07 Cargar datos en la pestaña de formulario para

cargar Datos relacionados al domicilio.


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.


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


2011

______________________________________________________________


Casos de Excepción

10 Validar datos de inscripción


válidos


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.


2011

______________________________________________________________


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


2011

______________________________________________________________


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 Clases


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



2011

______________________________________________________________


Capítulo VI

Diseño


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


Figura C10.F2: Diagrama de Iteración: Usuario Administrador Actualiza el reglamento para el descuento de puntos.


2011

______________________________________________________________


Figura C10.F3: Diagrama de Iteración: Usuario Actualiza los puntos a una categoría


2011

______________________________________________________________


Figura C10.F4: Diagrama de Iteración: Agente de Transito crea nueva infracción


2011

______________________________________________________________


Figura C10.F5: Diagrama de Iteración: Administrador actualiza preguntas y posibles respuestas


2011

______________________________________________________________


Figura C10.F6: Diagrama de Iteración: Administrador Actualiza examinadores en el sistema.


2011

______________________________________________________________


Figura C10.F7: Diagrama de Iteración: Administrador valida datos personales del conductor y la información queda actualizada para

poder ser usada oficialmente.


2011

______________________________________________________________


Figura C10.F8: Diagrama de Iteración: Conductor realiza Examen teórico


2011

______________________________________________________________


Figura C10.F9: Diagrama de Iteración: Examinador completa los resultados del examen. Caso de aplicación

Médico: Examen


2011

______________________________________________________________


Figura C10.F10: Diagrama de Iteración: Conductor se inscribe en el sistema


2011

______________________________________________________________


Figura C10.F11: Diagrama de Iteración: Usuario inicia Solicitud


2011

______________________________________________________________


1.3 Diagramas de Clases

Figura C10.F12: Diagrama de Clases al final de esta iteración.


2011

______________________________________________________________


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 Clases


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



2011

______________________________________________________________


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


2011

______________________________________________________________


Figura C10.F13: Diagrama de Iteración: Usuario inicia Solicitud – Segunda Iteración


2011

______________________________________________________________


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.


2011

______________________________________________________________



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


2011

______________________________________________________________



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


2011

______________________________________________________________


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


2011

______________________________________________________________


Se realiza las primeras pantallas, se corrige los diagramas de iteraciones

dando mayor información para revisar nuevamente las clases casi definitivas.


Diagrama de Clases


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



2011

______________________________________________________________


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


2011

______________________________________________________________


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


2011

______________________________________________________________


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


2011

______________________________________________________________



Figura C11.F1: Diagrama de Clases al final de esta iteración.


______________________________________________________________

1.7 Lista de Pantallas


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


2011

______________________________________________________________


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

______________________________________________________________


Listado de

módulos a actualizar por P01

OUT


______________________________________________________________ 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


2011

______________________________________________________________


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

______________________________________________________________


P02

OUT



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


2011

______________________________________________________________


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

______________________________________________________________


P03

completar los datos de un reglamento y las listas de infracciones que tenga relación.

Categoría.



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


2011

______________________________________________________________


Módulo: Reglamento y lista de

infracciones

asociadas

Proceso: Actualización

del Reglamento y las

infracciones asociadas


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

______________________________________________________________


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


______________________________________________________________


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


2011

______________________________________________________________


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

______________________________________________________________


P05

categorías y su asociación con preguntas, mostrando la cantidad de preguntas activas y aquellas que no se

OUT



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


2011

______________________________________________________________


Módulo: Lista de Preguntas

asociadas a una

categoría

Proceso: Actualización

de preguntas

asociadas a una

categoría.


: 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

______________________________________________________________


Actualización

P06

Pantalla para el Administrador con acceso a la actualización de Preguntas de una Categoría.



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


2011

______________________________________________________________


Módulo: Respuestas Asociadas

a Pregunta

Proceso: Lista de

Respuestas asociada a

Preguntas


: 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

______________________________________________________________


Respuestas asociada a P07

or con acceso a la actualización de Respuestas a una Pregunta.



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


2011

______________________________________________________________


Módulo: Respuesta Proceso: Actualización

de Respuesta.


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

______________________________________________________________


Actualización

P08

: Pantalla para el Administrador con acceso a la actualización de una Respuesta en particular

B02



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


2011

______________________________________________________________


Módulo: Datos Personales Proceso: Actualización

de Datos Personales

del solicitante


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

______________________________________________________________


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



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


2011

______________________________________________________________


Módulo: Domicilio Proceso: Actualización

de Domicilio del

Solicitante


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


B01

ADM

B01

B02

IN

IN

IN

IN

OUT

OUT

OUT

______________________________________________________________


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.


B02

ADM

ADM



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


2011

______________________________________________________________


Módulo: Carnet de Conducir Proceso: Visualización

de datos del carnet e

imagen.




OUT

OUT

OUT

OUT

OUT

OUT

OUT

______________________________________________________________


Visualización

P11




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


2011

______________________________________________________________


Módulo: Antecedentes Proceso: Visualización

de infracciones para el

solicitante,

Actualización para

administrador.


: 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

______________________________________________________________


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



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


2011

______________________________________________________________


Módulo: Ejecución manual de

ejecución de

descuento de puntos

Proceso: Ejecutar el

descuento de puntos

manual


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

______________________________________________________________


P13

Botón visible al ingresar a esta pantalla un usuario con permisos de administrador, ejecuta la infracción, sin esperar la



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


2011

______________________________________________________________


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

______________________________________________________________


Presionando

la opción “Si”, ejecuta P14



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


2011

______________________________________________________________


Módulo: Turnos Proceso: Listado de

Turnos y resultado de

examen realizado.


: 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

______________________________________________________________


Turnos y resultado de P15

Turnos para el conductor. Consulta y generación de turnos a los distintos exámenes.



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


2011

______________________________________________________________


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

______________________________________________________________


Consulta de

hículos y el P16

OUT



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.


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


2011

______________________________________________________________


Módulo: Inicio Proceso: Visualización

de noticias.


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.



Diagrama de Clases


Diagrama de Diseño

.T1: Diagrama de Clases – Clases no Expandidas - Final

OUT OUT

M01

M01

______________________________________________________________


Visualización

P17



Diagrama de

OUT


2011

______________________________________________________________


Capítulo VII

Conclusiones


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


Capítulo VIII

Bibliografía


2011

______________________________________________________________


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


2011

______________________________________________________________


Imagen – Iterative Development Image,

http://en.wikipedia.org/wiki/Image:Development-iterative.gif [Consulta: 5 de

mayo 2008]


2011

______________________________________________________________


Capítulo IX

Glosario


2011

______________________________________________________________


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


2011

______________________________________________________________


ANEXO I

Marco Teórico


2011

______________________________________________________________


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


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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)


2011

______________________________________________________________


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.


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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


2011

______________________________________________________________


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:


2011

______________________________________________________________


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.


2011

______________________________________________________________


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


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


2011

______________________________________________________________


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.


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]


2011

______________________________________________________________


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.


2011

______________________________________________________________



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.


2011

______________________________________________________________



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.


2011

______________________________________________________________


.

Impreso el día 06 de Agosto de 2014

seminario de sistemas - lu209598 -unsa

Documents