Rup Uml

LIBRO PARA LA ASIGNATURA DE ANALISIS DE SISTEMAS
AUTORES JUAN CARLOS GUEVARA BOLAOS Y LUIS FELIPE WANUMEN SILVA GRUPO DE INVESTIGACION METIS LINEA DE INGENIERIA DE SOFTWARE
ENFOQUE PRCTICO DE MODELAMIENTO BASADO EN UML CON JAVA EN DONDE SE INCLUYEN ALGUNOS PATRONES DE DISENO.
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLGICA SISTEMATIZACIN DE DATOS BOGOT D.C. 2008
TABLA DE CONTENIDO
TABLA DE CONTENIDO.....................................................................................................2 1. EL CRONOGRAMA EN RUP...........................................................................................7 2.1. LAS FASES Y LOS FLUJOS DE RUP......................................................................8 2.2. FASE DE INICIACION EN RUP.............................................................................11 2.3. FASE DE ELABORACION EN RUP.......................................................................13 2.4. FASE DE CONSTRUCCION EN RUP....................................................................15 2.5. FLUJO DE TRANSICION EN RUP.........................................................................16 2. CONSIDERACIONES AL REALIZAR SU PROYECTO DE GRADO.........................27 2.1. CONSIDERACIONES SOBRE LAS PALABRAS QUE DEBE INCLUIR EL DOCUMENTO DE GRADO O PROYECTO DE SOFTWARE.....................................27 2.2. SOBRE LA INTRODUCCION DE LA TESIS.........................................................28 2.2. SOBRE EL TITULO DE LA TESIS.........................................................................29 2.3. PLANTEAR OBJETIVOS GENERALES Y ESPECIFICOS...................................29 2.4. OTRAS COSAS SOBRE LOS OBJETIVOS ESPECIFICOS..................................31 2.5. CUIDADOS AL PLANTEAR EL ALCANCE DEL PROYECTO..........................32 2.6. COSAS HA TENER EN CUENTA EN EL PLANTEAMIENTO DEL PROBLEMA ...........................................................................................................................................33 EJEMPLO DESGLOSADO DE DESCRIPCION DEL PROBLEMA............................36 2.7. COSAS SOBRE LAS DELIMITACIONES..............................................................38 2.8. SOBRE EL ALCANCE Y LAS DELIMITACIONES..............................................38 2.9. COSAS SOBRE EL RIESGO....................................................................................38 2.10. COSAS HA TENER EN CUENTA SOBRE EL MARCO HISTORICO...............39 2.11. COSAS SOBRE EL MARCO CONCEPTUAL......................................................39 2.12. COSAS SOBRE EL MARCO REFERENCIAL.....................................................39 2.13. COSAS SOBRE LOS COSTOS DEL PROYECTO...............................................39 2.14. COSAS SOBRE LA FACTIBILIDAD OPERATIVA DEL PROYECTO.............40 2.15. COSAS SOBRE LA METODOLOGIA..................................................................40 2.16. COSAS HA TENER EN CUENTA EN EL MODELAMIENTO...........................40 2.17. TALLER PROPUESTO PARA MEJORAR LA FASE DE PLANEACION DEL PROYECTO......................................................................................................................41 2.18. TALLER PROPUESTO PARA PENSAR EN OBJETOS......................................44 3. GENERALIDADES DE UML.........................................................................................45 3.1. DIAGRAMAS DE CASOS DE USO........................................................................45 3.2. DIAGRAMAS DE ACTIVIDADES.........................................................................45 3.3. DIAGRAMAS DE CLASES.....................................................................................45 3.4. DIAGRAMAS DE INTERACCION.........................................................................45 3.5. DIAGRAMAS DE ESTADO....................................................................................46 3.6. DIAGRAMAS DE COMPONENTES.......................................................................46 3.7. DIAGRAMAS DE DESPLIEGUE............................................................................46 4. MODELANDO CON UML..............................................................................................46
4.1. MODELAMIENTO DEL DOMINIO DEL PROBLEMA........................................47 4.2. MODELAMIENTO DE LA SOLUCION DEL PROBLEMA..................................47 4.3. MODELAMIENTO DE LA CODIFICACION DEL PROBLEMA.........................47 5. MODELOS UML EN LOS FLUJOS DE TRABAJO RUP.............................................48 5.1. DIAGRAMAS USADOS EN EL FLUJO DE MODELADO DEL NEGOCIO.......49 5.2. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO REQUERIMIENTOS....50 5.3. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO ANALISIS Y DISENO. 50 5.4. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO IMPLEMENTACION...52 5.5. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO DESPLIEGUE...............53 5.6. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO PRUEBAS.....................54 6. EL LENGUAJE OCL.......................................................................................................57 6.1. OCL Y MOF..............................................................................................................57 6.2. UML Y OCL..............................................................................................................57 6.3. EVOLUCION DE OCL.............................................................................................58 6.4. COSAS QUE SE PUEDEN HACER CON OCL......................................................58 6.5. OCL Y LOS REQUISITOS.......................................................................................58 6.6. CONCLUSIONES SOBRE OCL..............................................................................59 6.7. BIBLIOGRAFIA SOBRE OCL.................................................................................59 7. SOBRE LOS CASOS DE USO EN UML 2.0..................................................................61 7.1. IDENTIFICAR ACTORES Y CASOS DE USO......................................................61 7.2. TIPOS DE RELACIONES ENTRE LOS CASOS DE USO.....................................63 7.3. IDENTIFICAR RELACIONES TIPO <<EXTENDS>>...........................................64 7.4. ERRORES COMUNES CON RELACIONES TIPO <<EXTENDS>>....................68 7.5. RELACIONES DE GENERALIZACION SIN ESTEREOTIPO..............................70 7.6. IDENTIFICAR RELACIONES TIPO <<USES>> O <<INCLUDE>>....................75 7.7. EJEMPLO DE RELACION TIPO <<USES>> O <<INCLUDE>>.........................77 7.8. CASO ESPECIAL DE RELACION TIPO <<USES>> O <<INCLUDE>>............78 7.9. DOCUMENTACION DE CASOS DE USO.............................................................79 8. MODELAMIENTO UML Y SU IMPLEMENTACIN EN JAVA................................86 8.1. DEFINICIN DE RELACIONES.............................................................................86 8.2. GENERALIZACIN VS HERENCIA....................................................................87 8.3. EL ACCESO PRIVADO...........................................................................................88 8.4. EL ACCESO PROTECTED......................................................................................90 8.5. ACCESO A LOS ATRIBUTOS: PRIVATE, PROTECTED O PUBLIC.................91 8.6. ASOCIACIONES......................................................................................................92 8.7. LAS AGREGACIONES............................................................................................93 8.8. RELACIONES DE DEPENDENCIA........................................................................96 8.9. HERENCIA MLTIPLE EN JAVA.........................................................................97 9. ESTEREOTIPOS DE LAS CLASES EN UML 2.0.........................................................98 9.1. LAS CLASES CON ESTEREOTIPO VIEW............................................................98 9.2. LAS CLASES CON ESTEREOTIPO TABLE..........................................................98 9.3. LAS CLASES CON ESTEREOTIPO SERVICE......................................................99 9.4. LAS CLASES CON ESTEREOTIPO RESOURCE..................................................99 9.5. OTROS ESTEREOTIPOS DE CLASES.................................................................100 10. P.O.O. EN JAVA Y CLASES ABSTRACTAS...........................................................104 10.1. LAS CLASES ABSTRACTAS.............................................................................104 10.2. CASO 1: SOBRE LAS CLASES ABSTRACTAS...............................................105
10.3. CASO 2: SOBRE LAS CLASES ABSTRACTAS................................................105 10.4. CASO 3: SOBRE LAS CLASES ABSTRACTAS................................................106 10.5. CASO 4: SOBRE LAS CLASES ABSTRACTAS................................................107 10.6. CASO 5: SOBRE LAS CLASES ABSTRACTAS................................................108 10.7. CASO 6: SOBRE LAS CLASES ABSTRACTAS................................................109 10.8. CASO 7: SOBRE LAS CLASES ABSTRACTAS................................................111 10.9. CASO 8: SOBRE LAS CLASES ABSTRACTAS................................................112 11. P.O.O. EN JAVA Y LAS INTERFACES.....................................................................113 11.1. LAS INTERFACES DEBEN INICIALIZAR SUS ATRIBUTOS........................114 11.2. EN LAS INTERFACES NO ES OBLIGATORIO MODIFICADORES DE ATRIBUTOS..................................................................................................................115 11.3. EL MODIFICADOR DE ATRIBUTO POR DEFECTO ES PUBLIC EN LAS INTEFACES...................................................................................................................115 11.4. EL MODIFICADOR DE ATRIBUTO PROTECTED NO ESTA PERMITIDO EN LAS INTERFACES........................................................................................................115 11.5. EL MODIFICADOR DE ATRIBUTO PRIVATE NO ESTA PERMITIDO EN LAS INTERFACES........................................................................................................116 11.6. UNA INTERFAZ NO PUEDE SER INSTANCIADA DIRECTAMENTE.........116 11.7. UNA CLASE NO INTERFAZ PUEDE IMPLEMENTAR UNA CLASE INTERFAZ.....................................................................................................................117 11.8. UNA CLASE INTERFAZ NO PUEDE IMPLEMENTAR UNA CLASE INTERFAZ.....................................................................................................................118 11.9. UNA CLASE INTERFAZ PUEDE EXTENDER DE UNA CLASE INTERFAZ .........................................................................................................................................120 11.10. UNA CLASE NO INTERFAZ PUEDE IMPLEMENTAR VARIAS CLASES TIPO INTERFAZ............................................................................................................121 11.11. UNA CLASE INTERFAZ PUEDE EXTENDER DE VARIAS CLASES TIPO INTERFAZ.....................................................................................................................122 11.12. UNA CLASE NO INTERFAZ NO PUEDE EXTENDER DE UNA CLASE TIPO INTERFAZ.....................................................................................................................123 11.13. NO SE PUDE MODIFICAR VARIABLE DE UNA CLASE TIPO INTERFAZ .........................................................................................................................................125 11.14. CLASE QUE IMPLEMENTE CLASE TIPO INTERFAZ DEBE DEFINIR SUS MTODOS.....................................................................................................................127 12. TODO A CERCA DE CLASES...................................................................................129 12.1. TIPOS DE CLASES..............................................................................................130 12.2. VARIABLES Y METODOS DE INSTANCIA....................................................130 12.3. AMBITO DE UNA VARIABLE...........................................................................131 12.4. METODOS Y CONSTRUCTORES......................................................................131 12.5. FINALIZADORES................................................................................................132 12.6. ALCANCE DE OBJETOS Y RECICLADO DE MEMORIA..............................132 13. EJERCICIO DEL PIRATA RESULADO DE LA PRIMERA ITERACION CON RUP .............................................................................................................................................134 13.1. PLANTEAMIENTO DEL ENUNCIADO............................................................134 13.2. ESTABLECIMIENTO DE FRASES IMPORTANTES........................................134 13.3. ESTABLECIMIENDO DE CLASES....................................................................135 13.4. PROGRAMA EN JAVA........................................................................................136
13.5. EJECUCIN DEL PROGRAMA:........................................................................141 14. EJERCICIO DEL AVION............................................................................................144 14.1. DIAGRAMA DE CLASE......................................................................................144 14.2. EXPLICACIN DE LA IMPLEMENTACIN...................................................145 14.3. EJECUCIN DEL PROGRAMA..........................................................................155 15. LA CLONACION DE OBJETOS................................................................................157 15.1. COPIA DE OBJETOS LIMITADA.......................................................................157 15.2. COPIAR OBJETOS CON INTERFAZ CLONEABLE........................................166 15.3. LA INTERFAZ CLONEABLE ABARCA SUBOBJETOS..................................169 16. CLASES TIPO OBSERVER Y OBSERVABLE.........................................................174 16.1. ESTRUCTURA DE LAS CLASES OBSERVABLES.........................................174 16.2. ESTRUCTURA DE LAS CLASES OBSERVER.................................................175 16.3. CREACION DE OBJETOS DE TIPO OBSERVER Y OBSERVABLE..............175 16.4. VINCULACION DEL OBJETO OBSERVABLE AL OBJETO OBSERVER....176 16.5. UN EJEMPLO COMPLETO CON OBSERVER Y OBSERVABLE..................176 16.6. PREGUNTAS SOBRE OBSERVER Y OBSERVABLE.....................................179 17. COMO DELEGAR CLASES.......................................................................................181 17.1. PLANTEAMIENTO TEORICO DE LA DELEGACION....................................181 17.2. EJERCICIO PRCTICO SOBRE DELEGACION..............................................184 17.3. PREGUNTAS SOBRE DELEGACION................................................................186 18. SERIALIZACION DE OBJETOS................................................................................187 18.1. SERIALIZAR UN OBJETO COMPLETAMENTE.............................................187 18.2. SERIALIZAR UN OBJETO COMPLETAMENTE EN JAVA............................189 18.3. ATRIBUTOS TRANSIENTES EN LA SERIALIZACION................................194 18.4. LA SERIALIZACION Y EL DIAGRAMA DE ESTADOS................................198 18.4. TALLER PROPUESTO SOBRE SERIALIZACION...........................................201 19. EJERCICIOS QUE TIENEN DIAGRAMAS DE SECUENCIA.................................206 19.1. MODELAMIENTO DE DETENCION SINCRONICA DE MULTIPLES HILOS CON UN EJEMPLO.......................................................................................................206 19.2. IMPLEMENTACION DE DETENCION SINCRONICA DE MULTIPLES HILOS CON UN EJEMPLO.......................................................................................................218 20. INTRODUCCION A LOS PATRONES DE SOFTWARE.........................................224 20.1. PATRONES CON FUNCIONALIDAD DE CREACIN....................................224 20.2. PATRONES CON FUNCIONALIDAD ESTRUCTURAL..................................224 20.3. PATRONES CON FUNCIONALIDAD DE COMPORTAMIENTO..................224 21. EXPLICACION DETALLADA DE LOS PATRONES..............................................224 21.1. EJEMPLO PRCTICO DE APLICACIN DE FACTORY................................224 21.2. EJEMPLO MAS ELABORADO USANDO FACTORY......................................228 22. PATRON DE CREACION SINGLETON....................................................................231 22.1. PARTE TEORICA DEL PATRON SINGLETON................................................231 22.2. PARTE PRACTICA DEL PATRON SINGLETON.............................................232 22.3. OBSERVACIONES AL EJERCICIO DE SINGLETON......................................233 23. SOBRE LA CALIDAD DEL SOFTWARE.................................................................235 23.1. MODELOS DE CALIDAD...................................................................................235 22.2. MODELO SPICE...................................................................................................238 23.3. NORMA ISO 9000-2000.......................................................................................239 23.4. NORMA ISO 90003..............................................................................................239
23.5. NORMA ISO/IEC TR 15504.................................................................................239 23.6. ESTANDAR ISO 9126..........................................................................................240 23.7. MODELOS CMMI................................................................................................241 23.8. TALLER PROPUESTO DE CALIDAD...............................................................243 24. LOS SISTEMAS DE CONTROL DE VERSIONES...................................................244 24.1. LOS CVS Y EL PROCESO DE DESARROLLO UNIFICADO..........................244 24.2. LA GESTION DE CONFIGURACIONES Y LOS CVS......................................245 24.2. CONTENIDO DE LA UNIDAD...........................................................................245 24.3. CONCRETANDO LO QUE ES UN CVS.............................................................246 24.4. TIPOS DE SISTEMAS DE CONTROL DE VERSIONES..................................246 24.5. LOS CVS Y LA INGENIERA DE SOFTWARE................................................247 24.6. SISTEMAS PARA GESTIONAR LOS CVS........................................................248 24.7. OTROS SISTEMAS QUE APOYAN A LOS CVS..............................................249 24.8. CARACTERISTICAS QUE DEBE TENER UN BUEN CONTROL DE VERSIONES...................................................................................................................249 24.9. EL FUTURO DE LOS CVS..................................................................................251 24.10. CONCLUSIONES SOBRE LOS CVS................................................................251 24.11. BIBLIOGRAFIA DE LA UNIDAD....................................................................252 24.12. INFOGRAFIA DE LA UNIDAD........................................................................253 25. BIBLIOGRAFIA...........................................................................................................256 25.1. BIBLIOGRAFIA SOBRE PROCESOS DE DESARROLLO Y RUP..................256 25.2. BIBLIOGRAFIA SOBRE MODELAMIENTO CON UML.................................256 25.3. BIBLIOGRAFIA SOBRE IMPLEMENTACIONES CON UML.........................257
1. EL CRONOGRAMA EN RUP
Una de las preocupaciones de los estudiantes de Ciencias Tecnolgicas e Ingenieras relacionadas con la Informtica es el hecho de hacer buenos cronogramas en sus proyectos de desarrollos informticos. Estos cronogramas deben ser acordes con las metodologas. En esta seccin se muestra a continuacin el diagrama que aparece en todos los documentos que hablan de RUP y con base en el se planteara como deducir un posible cronograma que tenga algo de coherencia con dicho diagrama. Para comenzar veamos primero el diagrama que aparece siempre y en todo documento de RUP:
D Diagrama tomado de unas diapositivas elaboradas por Maria Fernanda Diaz y Margarita Cardozo Galvis.
2.1. LAS FASES Y LOS FLUJOS DE RUP

El anterior diagrama se encuentra con otras formas como la siguiente:
Diagrama tomado del libro El lenguaje Unificado de Modelado. Addison Wesley Iberoamericana, Madrid, 1999. ISBN: 84-7829-028-1. Pag 29. Con lo cual podemos ver que a pesar de lo diferentes que parecen los dos anteriores diagramas, en realidad muestran lo mismo. Y muestran que en RUP existen dos tipos de flujos, tal como se muestra a continuacin: FLUJOS DE RUP
Flujos de trabajo de proceso
Flujos de trabajo de soporte
Diagrama elaborado por Luis Felipe Wanumen Silva.
Los flujos de trabajo de proceso son los flujos que se documentan y se acostumbran a presentar con diversos diagramas para documentar un sistema y en muchas Universidades colombianas se acostumbra a entregar solamente esta parte documentada como constancia del proceso de Ingeniera de Software aplicado al desarrollo del proyecto. Podramos pensar en la siguiente analoga: Las labores de un docente universitario son: 1. Dictar clases 2. Participar en proyectos institucionales 3. Investigar 4. Preparar clase 5. Atender estudiantes 6. Orientar pasantias y tesis 7. Participar en comits institucionales 8. Apoyar actividades de extensin de la universidad 9. Sacar tiempo para escribir sus materiales de clase. 10. Sacar tiempo para comer y alimentarse bien. 11. Sacarle tiempo a la familia y al descanso. 12. Analizar sus experiencias docentes vividas para mejorar en algunos aspectos. Claro, al amigo lector / estudiante, se estar preguntando: Cmo es que sacarle tiempo para comer y alimentarse bien es una de las labores de un docente?: La respuesta es sencilla y se puede responder con otra pregunta: Qu pasa si el docente no se alimenta, podr continuar con su labor como docente durante mucho tiempo, no se ver afectado su desarrollo profesional?. La respuesta es: Se requiere que el docente ejecute estas tareas para tener un buen desempeo laboral. Pues bien, en este caso esta tarea es una labor que no es tan necesario documentar, pero que si es necesario ejecutar para que se puedan dar las otras labores. Tenemos pues una subclasificacin de actividades de soporte, tal como muestra el siguiente diagrama: FLUJOS DE RUP
Flujos de trabajo de soporte relevantes para documentar
Flujos de trabajo de soporte NO relevantes para documentar
Pues bien, segn lo explicado anteriormente, los flujos de soporte deben ejecutarse, para que se puedan ejecutar los flujos de proceso. La pregunta que viene es: Se pueden ejecutar mal los flujos de soporte?. Se puede un docente alimentar mal?. La respuesta es: Lo puede hacer, pero esto poco a poco deteriorara el rendimiento del profesional como docente. En pocas palabras, estamos diciendo que un flujo de soporte ayuda para que los flujos de proceso se realicen bien o mal, dependiendo la forma como se realicen los flujos de soporte Para explicar otro concepto importante, seguiremos con nuestra analoga: Es posible que un docente dicte sus clases sin elaborar sus propios materiales de clase?. La respuesta es: Si, no es necesario que se hagan materiales de clase, se pueden usar las guias elaboradas por otros autores. Viene entonces la otra pregunta: Si se llegase a realizar algn material de clase por parte del docente, este material servira como documentacin del proceso de enseanza?. La respuesta es Si. Otra pregunta es: El realizar manuales de clase por parte del docente no mejorara el dominio que tiene el docente sobre la materia y no mejorara el proceso enseanza-aprendizaje?. La respuesta es Claro que si porque mejorara la calidad del proceso. Entonces tenemos que los flujos de soporte son muy tiles para medir la calidad de los flujos de proceso. En pocas palabras los flujos de modelado del negocio, requisitos, anlisis, diseo, implementacin, pruebas y despliegue son de buena calidad cuando se les realiza una buena gestin de configuracin, gestin de proyecto y se tienen en cuenta metodolgicamente las variables de ambiente que intervienen en la elaboracin del sistema. El resumen de lo dicho anteriormente se puede esquematizar mediante el siguiente diagrama:
FLUJOS DE RUP
Dan calidad a los flujos de proceso
Flujos de trabajo de soporte relevantes para documentar
Flujos de trabajo de soporte NO relevantes para documentar
LOS FLUJOS DE TRABAJO EN RUP
Los flujos de trabajo en RUP segn lo dicho hasta el momento estn clasificados en flujos de proceso y en flujos de soporte, en cada flujo de estos se encuentran ms subflujos que se resumen en la siguiente tabla: FLUJOS DE PROCESO Modelado del negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue FLUJOS DE SOPORTE Gestin del cambio y configuraciones Gestin del proyecto Entorno
De otra parte es interesante observar que las fases de RUP son las mostradas en el siguiente diagrama:
Iniciacin
Elaboracin Construccin FASES DE RUP Transicin
2.2. FASE DE INICIACION EN RUP

Y en cada una de estas fases se pueden presentar los flujos anteriormente mencionados. Por ejemplo en la fase de iniciacin podran presentarse flujos de modelamiento del negocio, de anlisis, de diseo e incluso de implementacin, pero los dos ltimos flujos se presentan en esta fase en un grado bajo o casi escaso, por no decir casi nulo. Decimos entonces que podemos incluir los flujos de anlisis y diseo e implementacin en la fase de iniciacin,
pero destinando pocos recursos de tiempo, presupuestales y dems para este tipo de flujos en dicha fase, con lo cual elaboramos la siguiente tabla:
FASE . FASE DE INICIACION 22%
FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO
PORCENTAJE 9,00%
REQUERIMIENTOS
5,00%
ANALISIS Y DISEO IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO ADMINISTRACION
1,00% 1,00% 0,00% 0,00% 2,00% 2,00%
AMBIENTE
2,00%
En donde queda claro que los flujos de anlisis y diseo e implementacin tienen una importancia pequea cuando se realizan dentro de la fase de iniciacin. En el ejemplo de la tabla anterior a estos flujos se les da una importancia de 1% a cada uno, e incluso se puede notar que a los flujos de test y despliegue se les da ninguna importancia. Para la elaboracin de la anterior grafica nos basamos en la observacin detallada de la parte que se seala con un cuadro grueso de color rojo en el siguiente dibujo:
2.3. FASE DE ELABORACION EN RUP

La tabla de la seccin anterior la podemos elaborar para las dems fases y obtenemos la tabla de la fase de elaboracin siguiente:
FASE . FASE DE ELABORACION 22% FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO PORCENTAJE 4,00%
REQUERIMIENTOS
4,00%
ANALISIS Y DISEO
5,00%
IMPLEMENTACION TEST PRUEBAS DESPLIEGUE
2,00% 1,00% 1,00%
CONFIGURACION Y MANTENIMIENTO ADMINISTRACION
2,00% 2,00%
AMBIENTE
1,00%
Que es muy coherente con lo expuesto en el diagrama inicial de RUP:
En donde se puede verificar que los flujos de pruebas y de despliegue son los que menos importancia tienen en esta fase y por eso se les da una importancia de 1%, debido a que en la grafica anterior aparece muy delgada la linea, pero de todas formas aparece. De otra parte es importante ver que el flujo de diseo es el mas importante en la fase de elaboracin, razn por la cual se le da una importancia de 5, en tanto que a los flujos de requerimientos y modelado del negocio se le da una importancia de 4. Obviamente estos valores son una cuestin subjetiva, producto de observar el grafico y calcular al ojo un valor de importancia para cada flujo basado en el rea que se le alcanza a ver a cada flujo en cada fase (La cual en el grafico se ve como una montaa).
2.4. FASE DE CONSTRUCCION EN RUP

Continuando con nuestro proceso, y teniendo en cuenta que la fase de construccin de RUP esta dada por el cuadro grueso de color mostrado a continuacin:
Podriamos pensar que un buen cronograma para la fase construccion acorde con el anterior diagrama es el siguiente:
Podramos proponer el siguiente cronograma para la fase de construccin de un sistema de informacin:

FASE . FASE DE CONSTRUCCION 30% FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO REQUERIMIENTOS ANALISIS Y DISEO PORCENTAJE 2,00% 2,00% 4,00%
IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO
10,00% 2,00% 1,00% 5,00%
ADMINISTRACION
3,00%
AMBIENTE
1,00%
En donde los valores de importancia son tomados en forma arbitraria, pero basndonos en las reas de las montaas del diagrama RUP en la fase de construccin.
2.5. FLUJO DE TRANSICION EN RUP

En forma anloga a la construccin de las fases anteriores, nos proponemos mostrar una propuesta de cronograma para la fase de transicin. Veamos:
FASE . FASE DE TRANSICION 26% FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO REQUERIMIENTOS ANALISIS Y DISEO IMPLEMENTACION PORCENTAJE 0,00% 1,00% 1,00% 4,00%
TEST PRUEBAS
3,00%
DESPLIEGUE
11,00%
CONFIGURACION Y MANTENIMIENTO
5,00%
ADMINISTRACION
1,00%
La cual esta basada en la fase de transicin que esta sealada en el siguiente grafico de RUP, mediante un cuadro grueso de color rojo:
Y ahora bien, con todo lo expuesto hasta el momento creo que ha llegado el momento de comenzar a definir actividades para cada uno de los flujos expuestos en las anteriores tablas, de tal forma que el numero y el tipo de actividades asociadas a cada fase sean medianamente proporcionales a la importancia que hemos dado en las anteriores tablas. Para esto tenemos que comenzar por averiguar y hacer listados preliminares de las posibles actividades que pueden ir en cada flujo de trabajo y despus de realizar todo este trabajo, se puede decir que para nuestro cronograma propuesto tenemos que las actividades con los flujos correspondientes para cada una de las fases y colocndoles la duracin en das para cada flujo son las que se muestran a continuacin:
FASE .
CRONOGRAMA BASADO EN RUP PLANTILLA FLUJOS DE TRABAJO
NEGOCIOS Y MODELAMIENTO
FASE DE INICIACION 22%
REQUERIMIENTOS ANALISIS Y DISEO IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO
ADMINISTRACION AMBIENTE
PORCENTAJE ACTIVIDAD Modelo de Dominio Establecimiento de viabilidad del sistema Establecimiento de factibilidad Tcnica del sistema Establecimiento de factibilidad Operativa del Sistema Establecimiento de factibilidad Legal del Sistema 9,00% Modelo de procesos Definicin de actores Lista preliminar de casos de uso Documentacin de las excepciones de los casos de uso Documentacin de descripcin de casos de uso Depuracin de los casos de uso 5,00% Modelo de casos de Uso 1,00% Lista preliminar de clases 1,00% Definicin de las caractersticas de la herramienta 0,00% 0,00% Creacin de casos de uso de prueba 2,00% Montaje de un servidor de pruebas Administracin del personal Administracin de recursos 2,00% Administracin de recursos de computo 2,00% Adquisicin del espacio de trabajo
DIAS
27
15 3 3 0 0 6
6 6
FASE .
FLUJOS DE TRABAJO
NEGOCIOS Y MODELAMIENTO
REQUERIMIENTOS
FASE DE ELABORACION 22% ANALISIS Y DISEO IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO ADMINISTRACION AMBIENTE
PORCENTAJE ACTIVIDAD Depuracin del Modelo De Dominio Depuracin del modelo de procesos 4,00% Diagnostico de viabilidad del sistema Depuracin de actividades de los actores Depuracin de requerimientos funcionales Depuracin de requerimientos no funcionales Documentacin de casos de uso Depuracin de la lista de casos de uso 4,00% Depuracin del diagrama final de casos de uso Elaboracin del Diagrama de secuencia Elaboracin del Diagrama de colaboracin Elaboracin del diagrama de estados Elaboracin de diagrama de actividad 5,00% Diagrama de actividades 2,00% Elaboracin del diagrama de componentes inicial Creacin de clases de prueba 1,00% Pruebas basadas en objetos 1,00% Elaboracin del diagrama de despliegue inicial Creacin de casos de uso de prueba 2,00% Montaje de un servidor de pruebas Administracin del personal Administracin de recursos 2,00% Administracin de recursos de computo 1,00% Adquisicin del espacio de trabajo
DIAS
12
12
15 6 3 3 6
6 3
FASE .
FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO REQUERIMIENTOS
ANALISIS Y DISEO
FASE DE CONSTRUCCION 30%
IMPLEMENTACION TEST PRUEBAS DESPLIEGUE
CONFIGURACION Y MANTENIMIENTO ADMINISTRACION AMBIENTE
PORCENTAJE ACTIVIDAD 2,00% Correccin de polticas con respecto a la misin y visin 2,00% Depuracin de casos de uso extendido Elaboracin de diagramas de clase final Elaboracin de diagramas de actividad finales Elaboracin de diagramas de secuencia finales Elaboracin de diagramas de colaboracin finales 4,00% Elaboracin de diagramas de estado finales 10,00% Elaboracin de diagrama de componentes final 2,00% Pruebas basadas en escenarios 1,00% Elaboracin de diagrama de despliegue final Establecimiento de un modelo de pruebas Montaje de un servidor de pruebas Montaje de un servidor de control de escenarios Montaje de un servidor de control de versiones de software Pruebas del servidor CVS Montaje de un servidor de subversiones 5,00% Montaje de un servidor de pruebas Administracin del personal Administracin de recursos 3,00% Administracin de recursos de computo 1,00% Mejoras locativas a la estructura fsica de trabajo
DIAS 6 6
12 30 6 3
15
9 3
FASE .
FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO REQUERIMIENTOS ANALISIS Y DISEO
IMPLEMENTACION
TEST PRUEBAS
DESPLIEGUE
CONFIGURACION Y MANTENIMIENTO
FASE DE TRANSICION 26%
ADMINISTRACION
PORCENTAJE ACTIVIDAD 0,00% 1,00% Depuracin de casos de uso extendido Depuracin del modelo de anlisis y colocacin de etiquetas 1,00% OCL Creacin de mdulos de interfaz de usuario Creacin de mdulos de lgica del negocio 4,00% Creacin de mdulos de acceso a datos Pruebas basadas en escenarios Pruebas unitarias de clase Pruebas de acoplamiento Pruebas de cohesin 3,00% Pruebas de concurrencia Empaquetamiento de componentes de lgica de aplicacin Empaquetamiento de componentes de acceso a datos 11,00% Empaquetamiento de componentes de interfaz grafica Distribucin de paquetes en los distintos nodos Establecimiento de un modelo de pruebas Montaje de un servidor de pruebas Montaje de un servidor de control de escenarios Montaje de un servidor de control de versiones de software Pruebas del servidor CVS 5,00% Montaje de un servidor de subversiones Montaje de un servidor de pruebas Administracin del personal Administracin de recursos 1,00% Administracin de recursos de computo
DIAS 0 3 3
12
33
15
Observe amigo lector / estudiante que hay flujos que son transversales a todas las fases y tienen mas o menos la misma duracin en todas las fases y lo mas interesante del asunto es que dichos flujos son precisamente los flujos de soporte que estbamos mencionando al comienzo de esta seccin. PREGUNTAS QUE VERIFICAN LO APRENDIDO 1. Cual de las siguientes afirmaciones son FALSAS (Si es que hay varias falsas): a. El cronograma es independiente de la metodologa usada. b. El cronograma en RUP, esta compuesto por los flujos de iniciacin, elaboracin, construccin y transicin. c. En la fase de elaboracin el flujo de implementacin es el ms importante. d. En la fase de elaboracin el flujo de anlisis y diseo es el ms importante. e. No todas las afirmaciones anteriores son falsas f. todas las afirmaciones de la a) a la e) son falsas g. todas las afirmaciones de la a) a la e) son verdaderas. 2. Cual de las siguientes afirmaciones son FALSAS (Si es que hay varias falsas): a. La gestin del proyecto es un flujo de proceso que se debe tener en cuenta nicamente durante las fases de inicio y elaboracin b. Una primera clasificacin de los flujos en RUP es: Flujos de proceso y flujos de soporte. c. La forma en que se realicen los flujos de soporte es decisoria a la hora de observar la calidad con la que se presentan los flujos de proceso. 3. Cual de las siguientes afirmaciones son FALSAS (Si es que hay varias falsas): a. Los dos flujos de anlisis y diseo mostrados en el diagrama de RUP clsico son dos flujos que hacen parte de los flujos de proceso y que se toman separadamente en dicho diagrama con el animo de resaltar que una cosa es el anlisis y otra el diseo. 4. Para el caso de las afirmaciones que son falsas en el anterior cuestionario amigo lector / estudiante escriba la razn por la que son falsas mediante la elaboracin de una afirmacin que sea verdadera y que controvierta la afirmacin falsa. A parte de la construccin de esta afirmacin se debe hacer una composicin de una justificacin que respalde dicha afirmacin. (Este punto vale lo mismo que todos los anteriores puntos reunidos, es decir este punto es medio parcial si lo contesta bien y si no lo contesta bien es medio parcial que haz perdido. Tambin es el nico punto que se califica por respuesta completa y conjunta bien contestada junto con la justificacin y la afirmacin que el lector / estudiante componga). Recordad que una pregunta o se responde bien o se responde mal, porque decir que una pregunta tiene dos falsas, cuando en realidad tiene tres falsas es no acertar con la respuesta. De otra parte decir que algo es falso cuando lo es, pero dar una justificacin errnea bien sea falsa o cierta de la afirmacin es no acertar con la respuesta a la pregunta. RESPUESTAS A PREGUNTAS DE LA SECCION
1. Las afirmaciones A, B, C, F y G son falsas 2. La afirmacin A es falsa 3. La afirmacin A es falsa 4. La justificacin de las afirmaciones falsas son: Afirmacin 1A El cronograma es independiente de la metodologa usada Respuesta: El cronograma es DEPENDIENTE de la metodologa usada Justificacin: Es falsa porque de acuerdo a la metodologa se plantea el cronograma, por ejemplo si la metodologa es una metodologa basada en las pruebas como en el caso de la metodologa XP, se tienen que hacer en todo momento pruebas de todo y para el caso de RUP, una metodologa que le da gran importancia a los requerimientos, vemos pues que aun cuando el proyecto a avanzado se deja la posibilidad que se sigan haciendo revisiones y ajustes a los requerimientos con el animo de lograr en la mejor medida que al sistema se le puedan corregir errores antes de tener el producto final. De otra parte las metodologas lineales deben reflejar esta linealidad en los cronogramas, en tanto que las metodologas iterativas como RUP, deben reflejar esta iteratividad en el cronograma. Afirmacin 1B El cronograma en RUP, esta compuesto por los flujos de iniciacin, elaboracin, construccin y transicin. Respuesta: El cronograma en RUP, NO esta compuesto por los flujos de iniciacin, elaboracin, construccin y transicin. Justificacin: Iniciacin, elaboracin, construccin y transicin son fases y no flujos en RUP. Afirmacin 1C En la fase de elaboracin el flujo de implementacin es el ms importante. Respuesta: En la fase de elaboracin el flujo de implementacin NO es el ms importante. Justificacin: En la fase de elaboracin el flujo de anlisis y diseo es el ms importante. Afirmacin 1F Todas las afirmaciones de la a) a la e) son falsas. Respuesta: Las afirmaciones A, B, C, F y G son falsas. Justificacin: En la fase de elaboracin el flujo de anlisis y diseo es el ms importante y esta afirmacin esta en el numeral D, con lo cual todas las afirmaciones de la a) a la e) no son falsas.
Afirmacin 2A: La gestin del proyecto es un flujo de proceso que se debe tener en cuenta nicamente durante las fases de inicio y elaboracin Respuesta: La gestin del proyecto es un flujo de SOPORTE que no solamente se debe tener en cuenta en las fases de inicio y elaboracin Justificacin: La gestin del proyecto no es un flujo de proceso, sino un flujo de soporte. El flujo de gestin del proyecto hace parte de una de las mejores practicas en forma implcita (en forma implcita, ya que las mejores practicas son: Administracin de requerimientos, desarrollo iterativo, modelamiento visual, verificacin de la calidad, arquitecturas con componentes y control de cambios) y algunas de estas mejores 6 practicas estn presentes en la gestin de un proyecto. Afirmacin 3A: Los dos flujos de anlisis y diseo mostrados en el diagrama de RUP clsico son dos flujos que hacen parte de los flujos de proceso y que se toman separadamente en dicho diagrama con el animo de resaltar que una cosa es el anlisis y otra el diseo Respuesta: Los dos flujos de anlisis y diseo mostrados en el diagrama de RUP clsico son UN solo flujo que hace parte de los flujos de proceso y que se toman conjuntamente para efectos del diagrama de resumen de la metodologa RUP Justificacin: El flujo se llama: Flujo de anlisis y diseo y es que sean dos flujos por separado. Esta afirmacin se puede corroborar observando detenidamente los diagramas que simplifican la explicacin de la metodologa RUP.
2. CONSIDERACIONES AL REALIZAR SU PROYECTO DE GRADO

2.1. CONSIDERACIONES SOBRE LAS PALABRAS QUE DEBE INCLUIR EL DOCUMENTO DE GRADO O PROYECTO DE SOFTWARE
Es importante que tenga en cuenta a la hora de plantear el proyecto de grado que no se deben colocar palabras como las mostradas en la siguiente tabla: PALABRAS PERMITIDAS NO RAZON POR LA QUE NO UNA PALABRA SE PERMITE PROPUESTA PARA REEMPLAZARLA Etc, entre otros. Deja entrever que existen Es mejor omitir la palabra y otros elementos no colocar una palabra que signifique lo mismo. Yo pienso que Dios es En los documentos de tesis Una alternativa es decir cosas Bueno y de investigacin se como: colocan afirmaciones Las comunidades cristianas respaldadas por una en todas sus expresiones comunidad o un grupo de entre las que figuran los personas relativamente catlicos, evanglicos y influyente como para ser ecumnicos expresan en sus aceptada por lo menos por diferentes acepciones de la un gremio. biblia que Dios es un ser infinitamente Bueno. Yo puedo concluir Deja entrever que la Con todo lo anterior se puede conclusin es subjetiva. concluir que Realice revisiones ortogrficas del documento de anteproyecto y proyecto definitivo antes de entregarlo a quienes lo revisan. Otras palabras que es importante no incluir en el documento de tesis o en el anteproyecto se muestran en las siguientes tablas: Palabra o frase que hay que sacar de una Las causas del fenmeno X son: tesis Razn por la que se debe sacar Basura, uno no puede identificar todas las causas de algn fenmeno, recuerde que hay muertos que no hacen ruido. La siguiente frase queda un poco mejor en Entra las causas mas visibles del la tesis fenmeno X podemos citar:
Palabra o frase que hay que sacar de una Para mi tesis Razn por la que se debe sacar Recuerde que el pensamiento individual o personal (experimental) no tiene validez La siguiente frase queda un poco mejor en Podemos encontrar que.. la tesis Palabra o frase que hay que sacar de una Lo dijo fulanito o sutangano tesis Razn por la que se debe sacar El hecho que lo halla dicho alguien muy importante no quiere decir que sea la verdad, cuantas veces al mejor panadero se le quema el pan. La siguiente frase queda un poco mejor en Los siguientes autores coinciden en la tesis afirmar que
2.2. SOBRE LA INTRODUCCION DE LA TESIS

Don de se encuentra la sntesis de los captulos (Cules son los aportes a la persona y al profesional?), debe tener para un que, un para que y un como.
2.2. SOBRE EL TITULO DE LA TESIS

Si usted amigo estudiante esta pensando en hacer un sistema de informacin debe saber que hay varios tipos de sistemas de informacin, a saber1: Los sistemas de informacin pueden clasificarse en transaccionales, de apoyo a las decisiones y estratgicos. Los transaccionales, se caracterizan porque a travs de ellos se automatizan las tareas y procesos operativos, se puede integrar gran cantidad de informacin institucional para ser utilizada posteriormente por los funcionarios de nivel operativo de la organizacin en la toma de decisiones. Los de apoyo a las decisiones, por su naturaleza misma apoyan la toma de decisiones repetitivas y no estructuradas, generalmente son desarrollados por el usuario final, proporcionan informacin de soporte para los mandos intermedios y la alta gerencia en el proceso de toma de decisiones. Los estratgicos, su funcin principal no es apoyar la automatizacin de los procesos operativos ni proporcionar informacin para apoyar la toma de decisiones, son desarrollados para uso interno, para lograr ventajas competitivas a travs de su implantacin y uso apoyando al nivel alto de la organizacin.
2.3. PLANTEAR OBJETIVOS GENERALES Y ESPECIFICOS

Existen en Ingeniera de Software algo llamado mtricas de software que son mtricas que intentan medir el software de acuerdo a ciertas caractersticas, por ejemplo existen mtricas de acoplamiento, de complejidad, de tamao, de suficiencia, de cohesin, de primitivismo, de volatilidad, de similitud, por mencionar algunas, y aunque son muchas las mtricas que los ingenieros de software han desarrollado, tambin son muchas las que no se han podido desarrollar debido bsicamente a las caractersticas de los sistemas. Por ejemplo no se han podido desarrollar mtricas de amigabilidad, por cuanto la amigabilidad es algo subjetivo que varia de un usuario a otro, es decir, podemos encontrarnos con dos usuarios de un mismo sistema y a uno de ellos le parece que el software es bastante amigable y fcil de usar en tanto al otro no le parece y es mas, le podra parecer que es poco amigable. Con todo lo anterior y teniendo en cuenta que los objetivos de un proyecto deben ser medibles, podemos afirmar que no se deben colocar en los objetivos palabras que no correspondan con mtricas que permitan evaluar el logro de mencionado objetivo, dado que se estaran colocando objetivos no medibles y si no es medible, no debe ser objetivo. Pensando en esta situacin se muestran a continuacin algunos objetivos que no parecen ser objetivos en el sentido estricto de la palabra. OBJETIVO QUE NO RAZON POR LA CUAL UNA PARECE SER OBJETIVO NO PARECE SER ALTERNATIVA
1
FORMA DE
Esta clasificacion fue tomada de http://www.virtual.unal.edu.co/cursos/enfermeria/2002847/lecciones/tematica4/subtema4-8.html
OBJETIVO Construir el sistema Aunque es posible medir el operativo mas pequeo. tamao del software por ejemplo usando las mtricas de cantidad de funciones, cantidad de lneas de cdigo, es bastante ambicioso este objetivo por cuanto es posible que salga en unos anos otras tecnologas que permitan construir sistemas operativos mas pequeos y en este momento se tendran problemas con el cumplimiento del objetivo. Construir el mejor sistema Es posible construir este operativo en cuento a objetivo y cumplirlo aunque seguridad de ingreso. con mucho esfuerzo, pero se corren muchos riesgos al plantear este objetivo y la razn es que la seguridad es un tema bastante espinoso que hasta el momento ninguna casa de software puede decir que no ha tenido problemas de seguridad, y si hasta el momento todos los fabricantes de software han tenido problemas con seguridad no es recomendable ser tan osado y atreverse a realizar afirmaciones como esta. Construir un sistema bonito No existen mtricas para medir lo bonito de un sistema.
COLOCAR EL OBJETIVO Construir un sistema operativo que respecto a los actuales este entre los 10 sistemas operativos mas pequeos del mundo.
Construir un sistema que permita la autenticacin basado en el estndar X para encriptacin de datos y usando el algoritmo Y como algoritmo de encriptacin de datos al momento de enviar datos hacia el servidor.
Construir un sistema No existen mtricas de agradable agradabilidad. Construir un sistema gil. Lo gil no solamente depende del programador o desarrollador del sistema, sino de la congestin de la red entre otros factores,
Construir un procesador de textos con una apariencia similar a la del procesador de textos Start Office. <<Este un objetivo mejorado, pero le falta mejorar mas>> Seria bueno suprimir este objetivo Construir un sistema que en condiciones normales de red permita realizar consultas a datos en menos de un minuto si la base de datos no ha
Desarrollar un sistema de registro de notas que permita agilizar los procesos de preinscripcin automtica de notas.
Desarrollar un sistema de consulta bibliotecaria Software educativo que permita mejorar el nivel de aprendizaje en java de los estudiantes y les permita aprobar los parciales propuestos por los profesores de sistematizacin de datos.
razn por la cual no es bueno colocar este objetivo que no solamente depende de los desarrolladores del sistema. El objetivo propuesto faltara todava depurarlo, pero tan solo se coloca para dar una idea de cmo enfocar el objetivo Es posible que el sistema permita agilizar los procesos de preinscripcin de notas, pero de ser esto lo que se quiere se debe tener en cuenta que el proceso como tal depende de otros factores y no del software en su totalidad. Esta bien, pero le falta mas cosas como en donde y que tipo de sistema va a ser. El software educativo es tan solo una herramienta que si es usada bien ayuda a mejorar los procesos de aprendizaje, pero en ningn caso reemplaza al docente.
alcanzado los 20000000 registros y la red tiene una velocidad promedio de 200 kb por segundo y no se presentan sistemas que interfieran con los puertos y servicios que usa el sistema en cada una de las maquinas. Colocar en alguna parte del documento algo que aclare que en condiciones normales de uso se cumplira, pero que el proceso se puede agilizar si existe la disposicin y las condiciones para que esto se de. Sistema intranet de consulta bibliotecaria en la Facultad Tecnolgica de la Universidad Distrital Desarrollar un material educativo computarizado que sirva de apoyo al proceso de enseanza de los principios de programacin orientada a objetos con Java.
2.4. OTRAS COSAS SOBRE LOS OBJETIVOS ESPECIFICOS

No debera haber menos de 3 objetivos especficos. Recuerde que en la mayora de las instituciones si usted cambia un objetivo especfico podra estar alterando el proyecto como tal y le tocara formular otro proyecto. Una forma de bosquejar los objetivos especficos es que vislumbre los menus principales del sistema y cuales serian las opciones principales del men principal y justamente estos correspondern con algunos de los objetivos especficos del proyecto de desarrollo de software. POR EJEMPLO SI EL PROYECTO ES Desarrollar un editor de textos.
ALGUNOS OBJETIVOS ESPECIFICOS SERAN Realizar un subsistema que permita la importacin y exportacin de documentos con el S.O. (Archivo) Desarrollar un subsistema que permita la manipulacin de texto al interior del documento presentando formas de tipo de letras y de fuentes diversas. = (Edicin) Desarrollar un subsistema que permita la visualizacin del documento en varias vistas incluyendo presentaciones personales y de impresin. RAZON DE LOS OBJETIVOS ESPECIFICOS Si usted observa las opciones principales que aparecen en la mayora de los editores de texto encuentra estas opciones. Osea que una forma de vislumbrar el asunto es observando aplicaciones que hagan cosas que usted esta haciendo en su proyecto de desarrollo de software, aunque no sean completamente iguales le darn una nocin de las opciones principales de men y de algunos de los objetivos del proyecto. Recuerde que hay algo de relacin con los subsistemas del proyecto, las opciones principales del men principal y los objetivos especficos, no se esta diciendo que las tres sean iguales, simplemente que hay algo de relacin. EJEMPLOS DE OBJETIVOS MAL REDACTADOS Disenar y desarrollar una base de datos. RAZON POR LA QUE ESTA MAL Las bases de datos son difciles de desarrollar porque ya estn desarrolladas a menos que uno la vaya a mejorar. CORRECTO. Disenar e implementar. EJEMPLOS DE OBJETIVOS MAL REDACTADOS Entender las necesidades de la organizacion RAZON POR LA QUE ESTA MAL Las necesidades son muy grandes y todas no se pueden abarcar. CORRECTO. Concretarlo mas.
2.5. CUIDADOS AL PLANTEAR EL ALCANCE DEL PROYECTO

AL momento de plantear el alcance de su proyecto tenga en cuenta algunos de los errores mas comunes que se presentan en proyectos de grado, como los siguientes: ALCANCE QUE NO ESTA RAZON POR LA QUE EL ALCANCE MEJORADO BIEN REDACTADO ALCANCE NO ESTA QUE POSIBLEMENTE BIEN REDACTADO. FALTE DEPURARLO El sistema alcanzara a ser el Es bastante osado este Sistema que valide la entrada sistema mas seguro en objetivo y esta subvalorando de los usuarios basado en el
Colombia.
la capacidad de otros mecanismo de clave y desarrolladores, cosa que nombre de usuario. nunca se puede hacer. El sistema usara cookies o sesiones para restringir el acceso a ciertos mdulos web.
Se sugiere que en los formatos de anteproyectos de grado no se quite esta parte de las limitaciones y alcance, por cuanto estos son importantes en la definicin del anteproyecto de grado.
2.6. COSAS HA TENER EN CUENTA PLANTEAMIENTO DEL PROBLEMA
EN
EL
No siempre lo que se ve como problema es un problema. Por ejemplo decir que: El problema es que mi pap lleva su contabilidad en un cuaderno, parece ser un problema, pero si vemos que los ingresos de mi padre no son muchos y como si fuera poco nadie le exige contabilidad y sus gastos ya no son artos por cuanto esta pensionado y sus hijos ya son independientes y como si fuera poco no tiene negocios, ni quiere tenerlos, diramos que lo que parecera ser un problema ya no lo es. Hay veces que los problemas no se dicen completos y esto hace que el problema no quede bien especificado. Por ejemplo el siguiente problema: El problema es que yo amo a Natalia Paris, puede ser entendido por algunos, pero otros no lo podrn comprender, pero si coloco el objetivo completo: El problema es que yo amo a Natalia Paris y ella no me ama, entonces vemos que el problema es bien claro. Y finalmente podemos decir que en el planteamiento del problema tenemos que las personas tienden a ver las soluciones a estos problemas de acuerdo a su rea de estudio y sus conocimientos y para comprender esto veamos la siguiente tabla: PROBLEMA PROFESION DEL QUE DIO LA SOLUCION. El seor Mario Silva Colocarle unas gafas. Oftalmlogo no ve bien por un ojo. SOLUCION LA SOLUCION NO SIEMPRE ES LA MEJOR Es posible que al colocarle gafas vea, pero la solucin ptima podra ser operarlo de la miopa, pero esta solucin no fue vista por cuanto el rea de conocimiento del que dio la solucin era un oftalmlogo que no sabia hacer operaciones de ojos.
Mi Padre tiene Desarrollar un Ingeniero problemas con su sistema contable para Sistemas contabilidad. las necesidades de mi Padre.
de A mi Padre no le gusta estar pegado a un computador y a duras penas usa Word cuando le toca y como si fuera poco sus contabilidades son pequeas y pueden caber perfectamente en una hoja de cuaderno. Y la razn del problema contable de mi Padre es que se le perdan las facturas, con lo cual la mejor solucin no era construir un sistema contable sino darle algunas nociones de archivstica y comprarle el legajador para que guarde sus facturas de las mesadas de su pensin. Es mas, usar el computador para sumar uno mas uno es mucha tecnologa, es como usar una escopeta para matar a una mosca.
Segn lo mostrado en el cuadro anterior queda el interrogante siguiente: Cmo hago para saber si algo es un problema que se puede solucionar con software?. Una de las formas para saber esto es haciendo uso de las cualidades de la informacin entre las que podemos encontrar: Veracidad Identidad Integridad Capacidad Seguridad Fiabilidad Confidencialidad Autenticacin No denegacin No repudiacin Accesibilidad
Si estas se llegan a ver afectadas muy seguramente es porque hay un problema de informacin y si el problema es de informacin muy posiblemente se puede atacar con la creacin de un sistema informtico. Si ninguna de estas caractersticas se ven afectadas es porque no es un problema que pueda ser solucionado por profesionales de la informacin, sino por otro tipo de profesionales, puede ser por mdicos, veamos un ejemplo de esto. PROBLEMA MAL SOLUCION PLANTEADO El problema es que Desarrollar un uso Excel para sistema informtico almacenar la en Access. informacin de 65536888888 clientes. CUALIDAD AFECTADA El problema no debe ser planteado como que se usa Excel, sino que en Excel la informacin para esta cantidad de registros no se guarda en forma segura, es mas ni siquiera se guarda. PLANTEAMIENTO MEJORADO PERO EN PROCESO El problema es que el sistema actual no permite almacenar en forma SEGURA la informacin de 65536888888 clientes.
Tambin hay que tener en cuenta hasta que punto el problema que al parecer es informtico no lo es, debido a factores no informatizables que afectan el problema. Por ejemplo. EJEMPLO DE PROBLEMA MAL PLANTEADO PLANTEMIENTO DEL PROBLEMA El problema es que la informacin se almacena no es veraz e integra. RAZON POR LA QUE EL PROBLEMA ESTA MAL PLANTEADO La razn es que la persona que lo almacena tiene problemas de digitacin por cuanto sus ojos y sus dedos presentan problemas. Vemos que el problema que parecera ser solucionable por medios informticos no puede ser solucionado debido a que las causales no son por mal funcionamiento del sistema en este aspecto. UN PLANTEAMIENTO NUEVO DEL PROBLEMA No es un problema para solucionar un profesional de la informtica. OTRO EJEMPLO DE PROBLEMA MAL PLANTEADO PLANTEMIENTO DEL PROBLEMA El problema es que la empresa no cuenta con un sistema de enseanza de las tablas de multiplicar. RAZON POR LA QUE EL PROBLEMA ESTA MAL PLANTEADO El planteamiento del problema debe dejar entrever que existen varias soluciones, y si segn el problema planteado la nica solucin es construir un sistema de enseanza de las tablas de multiplicar. Recordemos que en los problemas se tienen alternativas de solucin y la
forma como se defini el problema no da para construir alternativas de solucin. UN PLANTEAMIENTO NUEVO DEL PROBLEMA Los estudiantes solo tienen acceso a libros que muestran las tablas de multiplicar, pero por sus bajos recursos no cuentan con otros modelos pedaggicos que le permitan apropiarse del conocimiento de las tablas de multiplicar teniendo en cuenta que el modelo de libros solo es acorde con estudiantes que tienen psquicamente asociado un modelo repetitivo de aprendizaje, dejando por fuera a los que por su naturaleza tengan asociados otros modelos pedaggicos como el constructivista, el jerrquico, en didctico y el metdico. OTRO EJEMPLO DE PROBLEMA MAL PLANTEADO PLANTEMIENTO DEL PROBLEMA El problema es que la empresa usa Word para almacenar los datos RAZON POR LA QUE EL PROBLEMA ESTA MAL PLANTEADO Si el anterior problema es un problema tambin lo ser el siguiente: El problema es que la empresa usa Satara suit 4.5 para almacenar los datos. Pero, con seguridad este nuevo problema no es comprendido debido a que la herramienta Word es mas conocida por una mayora, mientras que Satara suit 4.5 no, con lo cual se tiene que si alguien desconoce Word no comprender el problema. Bueno, esto es una exageracin, pero muestra que el problema debe incluir la cantidad menor de tecnicismos posibles, obviamente hay momentos en los que es imposible quitarlos. UN PLANTEAMIENTO NUEVO DEL PROBLEMA El problema es que la empresa usa un procesador de textos que no tiene la capacidad para soportar el volumen de datos exigidos por la empresa. NOTA Se recomienda que en ningn formato de anteproyecto de grado se quite el planteamiento del problema. Se recomienda que en ningn formato de anteproyecto de grado se quiten las alternativas de solucin a los problemas.
EJEMPLO DESGLOSADO DE DESCRIPCION DEL PROBLEMA

Si el titulo del sistema es: Sistema multinivel para el registro nico nacional de talento humano en salud en el rea de recursos humanos del ministerio de la proteccin social. Comenzamos identificando componentes y elementos del dominio del problema. Componente1 = DERECHO LABORAL Componente12= ETICA FRASE QUE ENGLOBA EL KERNEL DEL PROBLEMA.
Formulacion se puede hacer mediante una pregunta, lo dicen muchos textos de metodologa de la investigacin. Como hacer para que los que ejerzan las profesiones en las areas de salud tengan la formacin para hacerlo? Segn el formato de la Universidad. Por que debera resolverse? Porque si personas no calificadas ejercen cargos en reas de la salud, se pueden presentar altos riesgos para la atencin a los usuarios del sector de la salud.
-Que soluciones existen actualmente y por qu debera buscarse nuevas soluciones.
Una solucin es una ley que sali para controlar y vigilar el ejercicio ilegal de las profesiones y ocupaciones en el rea de la salud.. La situacin actual Actualmente el manejo de la informacin para la expedicin de la tarjeta, consiste en diligenciar los documentos necesarios de una manera personalizada, generando retardos en la verificacin de los documentos ya que solo se realizara la comprobacin de los mismos cuando la entidad considere que hay suficientes solicitudes para empezar. Las races del problema Muchas personas no se capacitan para ejercer puestos en el rea de la salud y sin embargo ejercen usando ttulos falsos Situacin deseada Solamente los profesionales que tengan los requisitos establecidos por la ley pueden ejercer ocupaciones en el area de la salud. Comparacin entre lo actual y lo deseado. Se conocen resultados de aplicacin de estas soluciones en otras partes. En el mundo existen aplicaciones basadas en XML para intercambiar informacin entre sectores de la salud. Un estndar a nivel mundial para la realizacin de sistemas en el area de la salud es el HL7, el cual se encuentra en www.hl7.org. Por que profundizar en el tema Porque el desarrollo de sistemas de este permitiran contar con mejores beneficios en la formacin y atencin dentro de la disponibilidad dentro de la disponibilidad del sistema educativo y de servicios, con los menores riesgos para los usuarios de los servicios de salud.
2.7. COSAS SOBRE LAS DELIMITACIONES

Recuerde que en las delimitaciones se colocan las cosas que no me comprometo a hacer. SI EL PROYECTO ES Desarrollar un sistema para la enseanza de las tablas de multiplicar en grados tercero y cuarto de primaria de la Escuela la Alquera. UNA DELIMITACION SERIA Esta es una herramienta de apoyo al aprendizaje de las tablas de multiplicar en ningn momento podr ser usada para evaluar la capacidad de los nios en el tema de las tablas de multiplicar.
2.8. SOBRE EL ALCANCE Y LAS DELIMITACIONES

En la media de lo posible para proyectos de software es bueno bosquejar alcances y delimitaciones de acuerdo a la siguiente tabla: ALCANCE Y SUBDIVISION EXPLICACION EJEMPLOS DELIMITACION TECNICA PLATAFORMA LENGUAJE HARDWARE MODELADO INFRAESTRUCTA DE RED OPERATIVA FORMACION EXPERIENCIA ACADEMICA ESPACIO DISPOSICION FUNCIONAL NAVEGACIONAL ACTORES INTERNOS ESCENARIOS GEOGRAFICA TEMPORAL
2.9. COSAS SOBRE EL RIESGO

Recuerde que a todo proyecto hay que verle los riesgos no para no sufrir, sino para evitar que el impacto sobre el desarrollo del proyecto sea negativo frente a eventualidades y percances que se presenten en el entorno del proyecto.
SI EL PROYECTO ES Desarrollar un sistema para la enseanza de las tablas de multiplicar en grados tercero y cuarto de primaria de la Escuela la Alquera. UN RIESGO SERIA Cambien los equipos de la sala de sistemas y como REDP dona computadores y la Escuela no tiene suficientes recursos para adquirir licencias, adquieran equipos con S.O. Linux. Y Frente a este riesgo hay que establecer por lo menos dos planes: PLAN A Desarrollar un sistema que tambin se pueda ejecutar en Linux. PLAN B Desarrollar el software web en un servidor externo para que pueda ser accedido usando el navegador de internet de Linux.
2.10. COSAS HA TENER EN CUENTA SOBRE EL MARCO HISTORICO

Para mostrar por medio de un ejemplo como hacer un marco histrico, digamos que mi sistema es construir un sistema educativo para la enseanza de las tablas de multiplicar, con lo cual el marco histrico seria el siguiente: Como han evolucionado los sistemas educativos que ensenan las tablas de multiplicar. En un principio las tablas se aprendan a juete, despus se repeta como lora mojada, despus se inventaron las tablas giratorias, reglas aritmticas, memofichas la clave de sus estudios, las tablas cantadas, software de repeticin de tablas, software de combate que ensenan las tablas de multiplicar, sistemas expertos.
2.11. COSAS SOBRE EL MARCO CONCEPTUAL

En el marco conceptual se colocan diccionario de trminos raros y tcnicos.
2.12. COSAS SOBRE EL MARCO REFERENCIAL

En el marco referencial se colocan que otras empresas han hecho lo que el proyecto indica que se va a realizar.
2.13. COSAS SOBRE LOS COSTOS DEL PROYECTO

Recuerde que el software libre no es gratis. Recuerde que hay costos fijos y variables que deben ser tenidos en cuenta en sus proyectos.
2.14. COSAS SOBRE LA FACTIBILIDAD OPERATIVA DEL PROYECTO

Es necesario observar si los usuarios del sistema tienen las habilidades necesarias para manipular el sistema.
2.15. COSAS SOBRE LA METODOLOGIA

Sin importar la metodologa que escoja es importante tener en cuenta que no puede olvidar las cuatro p de la ingeniera de software que son: Producto Proceso Proyecto Personal Tambin es importante tener en cuenta que el presente documento esta pensado en proyectos de software que usen la metodologa RUP, junto con el lenguaje UML, como lenguaje de modelado. Si se piensa realizar un proyecto de software con otra metodologa es posible que este material no aporte lo que usted espera.
2.16. COSAS HA TENER EN CUENTA EN EL MODELAMIENTO

Es bueno tener en cuenta que en UML se pueden modelar clases y tambin se pueden modelar objetos. Por lo que los objetos del modelo de objeto de Documento DOM que usan los navegadores en sus JavaScript son plenamente modelables con UML. Recordemos que la especificacin UML 2.0 ha dicho que se pueden modelar paginas html cosa que no se poda hacer con las versiones anteriores de UML. Si un estudiante hace proyectos con lenguajes como PHP que no son del todo orientados a objetos, pueden perfectamente modelar todo lo que hagan si es que lo hacen sin usar la funcionalidad de objetos que provee la herramienta, otra cosa es que no usen la funcionalidad de objetos que permite el lenguaje como en el caso de PHP 5.0, que entre otras tiene muchos enemigos cuando de usar todas las caractersticas de objetos se trata debido a que muchos puritanos del modelamiento dicen que si se hace un sistema orientado a objetos que se haga en su totalidad orientado a objetos, pero no unas cosas con objetos y otras cosas estructuradas como pasara con PHP 5.0. Recordemos tambin que PHP es de orientacin a objetos y no orientado a objetos.
2.17. TALLER PROPUESTO PARA MEJORAR LA FASE DE PLANEACION DEL PROYECTO

PROFESOR: LUIS FELIPE WANUMEN SILVA Segn los proyectos que han establecido en el ultimo taller en donde establecida el titulo del trabajo, el objetivo general, el objetivo especifico, los recursos usados, la factibilidad, tcnica operativa, factibilidad econmica, requerimientos funcionales, requerimientos legales, requerimientos legales y de instalacin responda las siguientes preguntas: Establezca los sustantivos del titulo del proyecto que usted va a realizar para clase. Establezca los sustantivos de los objetivos generales del proyecto que usted va a realizar. Llene la siguiente tabla: Sustantivos que no Sustantivos que aparecen en objetivo aparecen en el titulo alguno, pero que usted cree que hacen parte del sistema. Sustantivos que aparecen en el objetivo general Sustantivos que aparecen en los objetivos especficos
Llene la siguiente tabla: Acciones que debe desempear el sistema, pero que no estn en el titulo, ni en el objetivo general, ni especifico.
Lista de verbos que aparecen en el titulo del proyecto
Empresa, sustantivo, persona, cargo, departamento o similar con el que se encuentra asociada la accin de la anterior columna.
Llene la siguiente tabla: Acciones que debe desempear el sistema, pero
Lista de verbos que aparecen en el titulo del
Empresa, sustantivo, persona, cargo,
que no estn en el titulo, ni en el objetivo general, ni especifico.
proyecto
departamento o similar con el que se encuentra asociada la accin de la anterior columna.
Llene la siguiente tabla: Acciones que debe desempear el sistema, y que se encuentran en el objetivo general del proyecto.
Acciones que debe desempear el sistema, y que se encuentran en los objetivos especficos del proyecto.
Llene la siguiente tabla: Lista de acciones que son desempeadas por personas de carne y hueso, y que tambin debe desempear el sistema.
Lista de acciones que son desempeadas por personas de carne y hueso pero que no son desempeadas por el sistema o software que usted a va realizar.
Lista de acciones que son desempeadas por el sistema, pero que no son desempeadas por el sistema.
Llene la siguiente tabla: Lista de actores del sistema
Lista de acciones
Espero que esta vez, si entreguen el trabajo, no como la vez pasada que no lo entregaron, sino tan solo unos pocos, porque de no entregarlo, la nota de talleres le queda en CERO.
2.18. TALLER PROPUESTO PARA PENSAR EN OBJETOS

1. Construir la clase denominada Circulo que permita a. Definir el centro y el radio b. Calcular su area c. Calcular la longitud de la circunferencia d. Un metodo que muestre todos los atributos del objeto Esta clase debe heredar de la clase punto para definir su centro 2. Construir la clase Cilindo que herede de la clase Circulo que permita: a. Calcular su volumen b. Un metodo que muestre todos los atributos del objeto 3. Construir la clase Cono que herede de la clase Circulo que permita a. Calcular su volumen V = 1/3(Area*h) b. Calcular su area total At = Pi*r(g+r) c. Un metodo que muestre todos los atributos del objeto El area debe ser un atributo heredado y g es la hipotenusa que forma h y r del cono 4. Estas clases deben ser construidas en lenguaje JAVA y los datos de los objetos deben ser ingresados por el usuario. Mentalidad para solucionar y pensar en orientacin a objetos. Se debe usar la herencia y aplicar conceptos de programacin orientada a objetos. Para las dos horas de Clase: 1. Hacer los diagramas de casos de uso 2. Construir el diagrama de secuencia 3. Construir los diagramas de Actividad Individual. Hora de Entrega 4:00 PM Da de entrega: 01 de Abril de 2008 Para la prxima Clase 4. Construir el programa, pensando mentalmente que quede con un correcto diagrama de secuencia (en Java Obviamente se realiza el programa) (El complique es que el programa debe ser un autnomo.)
3. GENERALIDADES DE UML
UML es un lenguaje que tiene elementos, relaciones y diagramas, tal como se especifica en la siguiente tabla Elementos VISION GENERAL DE UML Elementos estructurales Elementos de comportamiento Elementos de agrupacin Elementos de anotacin Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diagrama de secuencia Diagrama de colaboracin Diagrama de estado Diagrama de actividad Diagrama de componentes Diagrama de despliegue
Relaciones Diagramas
3.1. DIAGRAMAS DE CASOS DE USO

Son los encargados de documentar los requisitos de sistema a nivel general.
3.2. DIAGRAMAS DE ACTIVIDADES

Son equivalentes a los diagramas de flujo de las metodologas estructuradas y se usan para analizar procesos.
3.3. DIAGRAMAS DE CLASES

Muestran la vista esttica del sistema, con sus clases y las relaciones entre las mismas.
3.4. DIAGRAMAS DE INTERACCION

En UML existen dos tipos de diagramas de interaccin que son:
Diagramas de secuencia y Diagramas de colaboracin. Tambin se denominan diagramas isomorfos debido a que a partir de un diagrama se puede obtener el otro, es decir que a partir del diagrama de secuencia se puede obtener el diagrama de colaboracin y viceversa, a partir del diagrama de colaboracin se puede obtener el diagrama de secuencia.
3.5. DIAGRAMAS DE ESTADO

Muestra el estado cambiante de un solo objeto
3.6. DIAGRAMAS DE COMPONENTES

Muestra una vista esttica de los componentes que estn implementados en el sistema y sus relaciones, las cuales son las mismas que las existentes en los diagramas de clases, y esto, debido a que se presume que al interior de cada componente van una o varias clases y por tanto las relaciones entre estas clases son las que marcan la pauta de las relaciones que deben llevar estos componentes.
3.7. DIAGRAMAS DE DESPLIEGUE

Muestra una visin general que incluye los nodos que son los elementos que contienen los componentes del sistema.
4. MODELANDO CON UML

El problema del modelado se puede enfocar desde tres puntos de vista:
Modelar el Dominio del problema
Modelar la solucin del problema
Modelar la codificacin del problema
Y cada modelamiento debe verse desde varios puntos de vista. A continuacin veremos que algunos de estos modelamientos son mas cercanos a la codificacin y otros son menos cercanos a la codificacin (Cuando se habla de codificacin, se hace referencia en este material a cdigo fuente). Podemos decir que se despus de modelar el dominio del problema, se esta en disposicin de modelar la solucin del problema y transitivamente despus de modelar la solucin del problema se esta en disposicin de modelar la codificacin del problema.
4.1. MODELAMIENTO DEL DOMINIO DEL PROBLEMA

El dominio del problema es todo el conocimiento expresado en diagramas que asegure que el tema que se va a implementar se conoce, en pocas palabras que la lgica de negocio se conoce, que se tienen definidos los requerimientos del sistema y que se tienen identificadas las funcionalidades que debe desempear el sistema. En el modelamiento del negocio se debe modelar su parte dinmica como su parte esttica. Por lo general se acostumbra a modelar la parte dinmica del negocio por medio de un modelo de procesos y la parte esttica del negocio por medio de un modelo de dominio. Tenemos pues la siguiente tabla: MODELAMIENTO DEL NEGOCIO MODELAMIENTO PARTE ESTATICA MODELAMIENTO PARTE DINAMICA FORMA DE MODELARLO Modelo de Dominio Modelo de procesos
4.2. MODELAMIENTO DE LA SOLUCION DEL PROBLEMA

MODELAMIENTO DE SOLUCION MODELAMIENTO PARTE ESTATICA MODELAMIENTO PARTE DINAMICA FORMA DE MODELARLO Diagrama de clases Diagrama de estado Diagrama de casos de uso Diagrama de secuencia Diagrama de colaboracin Diagrama de Actividad
4.3. MODELAMIENTO DE LA CODIFICACION DEL PROBLEMA
MODELAMIENTO DE LA FORMA DE MODELARLO CODIFICACION DEL PROBLEMA MODELAMIENTO PARTE ESTATICA Diagrama de Clases Diagrama de componentes Diagrama de despliegue MODELAMIENTO PARTE DINAMICA Diagrama de objetos Diagrama de secuencia Diagrama de colaboracin Diagrama de actividad
5. MODELOS UML EN LOS FLUJOS DE TRABAJO RUP

Teniendo en cuenta que para modelar con UML disponemos de los siguientes diagramas Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diagrama de secuencia Diagrama de colaboracin Diagrama de estado Diagrama de actividad Diagrama de componentes Diagrama de despliegue Y que los flujos de trabajo de RUP son: FLUJOS DE PROCESO Modelado del negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue FLUJOS DE SOPORTE Gestin del cambio y configuraciones Gestin del proyecto Entorno
A continuacin vamos a bosquejar los diagramas que se pueden asociar con cada uno de dichos flujos de RUP.
5.1. DIAGRAMAS USADOS EN EL FLUJO DE MODELADO DEL NEGOCIO

Teniendo en cuenta Modelado del negocio Diagrama de casos de uso Diagrama de clases En bajo porcentaje En alto porcentaje, pero diagramas de clases globales Requisitos Anlisis Implementacin Despliegue Pruebas y Diseo
Diagrama de objetos Diagrama de secuencia Diagrama de colaboracin Diagrama de estado Diagrama de actividad Diagrama de componentes Diagrama de despliegue En alto porcentaje
5.2. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO REQUERIMIENTOS

Modelado del negocio Diagrama de casos de uso Diagrama de clases En bajo porcentaje En alto porcentaje, pero diagramas de clases globales Requisitos Anlisis Implementacin Despliegue Pruebas y Diseo En alto porcentaje
Diagrama de objetos Diagrama de secuencia Diagrama de colaboracin Diagrama de estado Diagrama de actividad Diagrama de componentes Diagrama de despliegue En alto porcentaje En un bajo porcentaje En un bajo porcentaje En bajo porcentaje
5.3. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO ANALISIS Y DISENO
Diagrama de casos de uso
Modelad o del negocio En bajo porcentaj e
Requisito s En alto porcentaj ee incluyend o casos de uso extendido s
Anlisis y Diseo
Implementa cin
Despliegu e
Pruebas
Diagrama de clases
En alto porcentaj e, pero diagrama s de clases generales
Diagrama de objetos
Diagrama de secuencia Diagrama de colaboraci n Diagrama de estado Diagrama de actividad Diagrama de En alto porcentaj e
En bajo porcentaj e
En alto porcentaje, incluyendo funcionalidad es que no estaban en la fase de modelado del negocio. En alto porcentaje, sobre todo en el flujo de diseo, mas que en el de anlisis. En alto porcentaje En alto porcentaje
En un bajo porcentaj e En un bajo porcentaj e
En alto porcentaje En alto porcentaje
component es Diagrama de despliegue
5.4. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO IMPLEMENTACION

Modelad o del negocio En bajo porcentaj e Requisito s En alto porcentaj ee incluyend o casos de uso extendido s En alto porcentaje, incluyendo funcionalidad es que no estaban en la fase de modelado del negocio. En alto porcentaje, sobre todo en el flujo de diseo, mas que en el de anlisis. En alto porcentaje En alto Anlisis y Diseo Implementaci n Despliegu Prueba e s
Diagrama de clases
Diagrama de objetos
Diagrama de secuencia Diagrama
En bajo porcentaj e
En alto porcentaje En bajo
de colaboraci n Diagrama de estado Diagrama de actividad Diagrama de component es Diagrama de despliegue En alto porcentaj e En un bajo porcentaj e En un bajo porcentaj e
porcentaje
porcentaje
En alto porcentaje En alto porcentaje En alto porcentaje
5.5. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO DESPLIEGUE

Modelad o del negocio En bajo porcentaj e Requisito s En alto porcentaj ee incluyend o casos de uso extendido s En alto porcentaje, incluyendo funcionalidad es que no estaban en la fase de Anlisis y Diseo Implementaci n Despliegu Prueba e s
Diagrama de clases
Diagrama de objetos
Diagrama de secuencia Diagrama de colaboraci n Diagrama de estado Diagrama de actividad Diagrama de component es Diagrama de despliegue En alto porcentaj e
En bajo porcentaj e
modelado del negocio. En alto porcentaje, sobre todo en el flujo de diseo, mas que en el de anlisis. En alto porcentaje En alto porcentaje
En alto porcentaje En bajo porcentaje
En alto porcentaj e En bajo porcentaj e
En alto porcentaje En alto porcentaje En alto porcentaje En alto porcentaj e
5.6. DIAGRAMAS USADOS EN EL FLUJO DE TRABAJO PRUEBAS

Modelad o del negocio En bajo Requisito Anlisis y s Diseo En alto Implementaci n Desplieg ue Pruebas En alto
Diagrama
de casos de uso
porcentaj e
porcentaj ee incluyen do casos de uso extendid os En alto porcentaje, incluyendo funcionalidad es que no estaban en la fase de modelado del negocio. En alto porcentaje, sobre todo en el flujo de diseo, mas que en el de anlisis. En alto En alto porcentaje porcentaje En alto porcentaje En bajo porcentaje
porcenta je
Diagrama de clases
En alto porcenta je
Diagrama de objetos
En alto porcenta je
Diagrama de secuencia Diagrama de colaboraci n Diagrama de estado Diagrama de actividad Diagrama de component es Diagrama de En alto porcentaj e
En bajo porcentaj e
En alto porcentaj e En bajo porcentaj e
En alto porcenta je En alto porcenta je En alto porcenta je En alto porcenta je
En alto porcentaje En alto porcentaje En alto porcentaje En alto porcentaj
En alto porcenta je En alto porcenta
despliegue
je
6. EL LENGUAJE OCL
La presente seccin pretende mostrar una breve introduccin a lo que es lenguaje OCL pero desde el enfoque de compararlo con otras cuestiones de UML. Comienza el trabajo explicando la diferencia entre OCL y MOF, despus entre OCL y UML. Ms adelante se escriben las cosas ms importantes de la evolucin de OCL y de las cosas que se pueden hacer con OCL. Continuando se muestra la simbiosis existente entre OCL y los requisitos. Al finalizar se muestran en forma de conclusiones ventajas y desventajas de UML. El lenguaje OCL ha sido desarrollado a la par que el lenguaje de modelado UML, y por ello, podemos decir que es difcil que hablemos de OCL sin hablar de UML. [1]
6.1. OCL Y MOF

El lenguaje de modelado UML es tan completo que incluso permite definirse as mismo, claro que dentro de unos parmetros como para no perderse la esencia inicial de UML. De otra parte es importante tener en cuenta que MOF es un lenguaje para definir lenguajes de modelado y obviamente desde este punto de vista debera estar bien acorde con UML, pero la verdad es que cuando se habla de UML 1.0 existen algunas diferencias entre ste y UML y por lo tanto algunas diferencias entre el OCL que se tenia en la versin OCL 1.0 y el OCL por ejemplo de la versin que acompaa a UML 1.5. [3] Todo lo anterior nos da a entender que el lenguaje de restriccin de objetos est ntimamente relacionado con el lenguaje UML y a su vez UML est relacionado en forma estrecha con MOF, de lo cual se desprende que indirectamente podramos pensar que cualquier versin de OCL no compagina muy bien con cualquier versin de MOF. [1]
6.2. UML Y OCL

La idea general no es que UML dependa de OCL, sino que OCL se construye cuando se ven ciertas deficiencias en alguna especificacin UML y se saca otra versin UML mejorada. [3] Otro aspecto que es necesario comprender es el aspecto de la independencia que debe existir entre OCL y UML para unas cosas y la dependencia para otras cosas. Por ejemplo, si no existiera UML no habra razn alguna para hablar de OCL, pero si no existiera OCL se podra pensar en UML como un lenguaje en el cual se dejara al libre albedro de los diseadores la especificacin de condiciones invariantes que deben cumplirse. [1] [3]
Es importante notar que UML usa OCL, pero UML en ningn momento depende de OCL. Sin embargo los cambios y las mejoras hechas a OCL no tienen porque cambiar la estructura de UML y en forma recproca los cambios hechos a UML en ningn momento tienen porque afectar al lenguaje OCL y es sta situacin la que habla de la independencia entre UML y OCL. [3] Algunos autores hablan de lo anteriormente mencionado diciendo que la especificacin OCL no puede alterar la especificacin del modelo grfico[1] [3] Lo que hace UML, no lo hace OCL y lo que no hace OCL no lo puede hacer UML, lo que muestra una relacin de complementariedad entre OCL y UML.
6.3. EVOLUCION DE OCL

OCL en su primera versin lo que haca y an lo sigue haciendo es brindando la sintxis necesaria para colocar especificaciones a un modelo UML, lo que sucede es que dichas especificaciones no siempre le dan precisin y consistencia, debido a que las herramientas no siempre usan dichas especificaciones de la misma manera. [4] Por todo esto, se puede decir que no solamente es necesario revaluar algunos aspectos de UML, sino de su lenguaje OCL. Como ejemplo claro de dicha revaluacin se trabaja pues la versin UML 2.0 en la cual se desean corregir algunos de estos problemas[1]. De todas formas algo que si es natural es que todava se tengan que reevaluar algunos aspectos tanto de UM como de OCL, debido a que es muy corto el tiempo que lleve ste lenguaje y son demasiadas las situaciones venideras que todava no se tienen en cuenta. [4] La versin de OCL RFP ms conocida es la versin OCL 2.0 que en verdad fue denominada UML 2.0 OCL RFC adoptado en agosto de 2003 y ofrece todos los elementos necesarios para ser integrada a UML 2.0 ofreciendo un lenguaje que permita especificar restricciones de objetos acordes al metamodelo de UML.
6.4. COSAS QUE SE PUEDEN HACER CON OCL

[1] Describir guardas en los diagramas de estados. Navegar a travs de los modelos grficos. Especificar restricciones en las operaciones [4]
6.5. OCL Y LOS REQUISITOS

Es interesante notar que un diagrama UML y concretamente un diagrama de Casos de Uso que no tenga especificados sus elementos OCL completamente , todava no es un diagrama
que capture los requisitos, pues las cuestiones puntuales de los requisitos por lo general se especifican con OCL. No olvidar que de todas formas OCL puede estar presente en casi cualquier diagrama de UML, con lo cual se puede decir que ayuda a ir enriqueciendo la semntica y el significado de cada uno de los mismos.
6.6. CONCLUSIONES SOBRE OCL

1. OCL tiene la ventaja de ser un lenguaje ms fcil que cualquier otro lenguaje de programacin y ello facilitara su uso [1] 2. Tiene la ventaja de poderse utilizar para especificar invariantes en las clases, tipos y estereotipos. 3. Otra ventaja es que con el uso de OCL en modelos UML y dado que OCL sirve para describir las operaciones en base a pre y post condiciones los modelos que se construyan en UML y que estn correctamente especificados con OCL adquieren una mayor claridad para el usuario de dicho modelo. 4. Anteriormente se mencionaba que con OCL se podan especificar restricciones en las operaciones y esto trae grandes beneficios a los desarrolladores bien juiciosos pues les dejara una buena documentacin sobre la implementacin de muchos mtodos. 5. Por ser un lenguaje parecido al lenguaje de programacin puede en algunas ocasiones a llegar a ser inentendible para algunos diseadores que no programen mucho. 6. Al ser demasiado extenso se hace bastante largo el estudio de OCL 7. OCL ayuda a que los modelos UML tengan coherencia.
6.7. BIBLIOGRAFIA SOBRE OCL

[1] http://www.afm.sbu.ac.uk/logic/ [2] Depetris, S. Aguera y H. Leone. "Introduccin a la Programacin Orientada a Objetos. Apuntes del curso". (1995). [3] http://www.vico.org [4] OMG Unified modeling language specification. Version 1.3. Cap. 7 : OCL. Publicat per lObject Management Group http://www.omg.org/ . The Object constraint language : precise modeling with UML. Jos B. Warmer, Anneke G. Kleppe. Addison-Wesley, 1998 .
7. SOBRE LOS CASOS DE USO EN UML 2.0

Los casos de uso son una de las formas mas conocidas para capturar requerimientos. Esto no quiere decir que sean la nica forma para capturar requerimientos.
7.1. IDENTIFICAR ACTORES Y CASOS DE USO

Es importante notar que los actores son entidades autnomas desde la perspectiva del sistema que se esta desarrollando. Por ejemplo una aplicacin de gestin de ventas que requiera informacin del sistema de nomina, no vera al sistema nomina como una persona de carne y hueso, pero si la vera como un ente autnomo que solicita informacin en un determinado momento. Esto es importante que se tenga en cuenta, si el ente autnomo solicita informacin al sistema es prudente colocar a este ente como un actor. Algunas cosas que nos ayudan a identificar actores es pensar en funcionalidades que debe prestar el sistema en relacin con los clientes que requieren esta funcionalidad. Y en este punto la mayora de las veces se puede ver que estas funcionalidades estn especificadas en el manual de funciones de algn funcionario, pero esto no siempre sucede, caso en el cual hay que tener un poco de astucia y sentido comn para capturar estas funcionalidades. Tal vez esta puede ser la razn por la cual se acostumbra a relacionar siempre actores con cargos y funciones, pero en algunos casos esto no siempre funciona segn lo explicado anteriormente. Suponga que estamos desarrollando un sistema de informacin sobre quejas y reclamos a clientes. Algunas de las funcionalidades de un sistema como este serian:
Envio de quejas a la empresa Captura de quejas del cliente Solicitud de envio de queja a Empresa Almacenamiento de quejas de clientes Seguimiento de queja expuesta por el Cliente Evaluacion de quejas no atendidas Evaluacion de quejas atendidas
Es importante notar que estas funcionalidades a veces ocurren con una secuencialidad, razn por la cual es necesario conocer previamente a esta fase los procesos de la organizacin para poder establecer esta secuencialidad y conocer el dominio de aplicacin del sistema con respecto a la empresa en la que va a funcionar el mismo. En otras palabras podramos decir que estas funcionalidades tienen mas o menos las siguientes relaciones en un flujo de procesos de la empresa:
Solicitud de envio de queja a Empresa Captura de quejas del cliente
Almacenamiento de quejas de clientes Envio de quejas a la empresa
Evaluacion de quejas atendidas
Seguimiento de queja expuesta por el Cliente
Evaluacion de quejas no atendidas
Es importante notar que el anterior diagrama nunca se coloca en UML, pero si se observa desde el punto de vista de procesos de la empresa, se tiene un diagrama de procesos de la empresa. Bueno, continuando con nuestro proceso de establecer actores en este punto es importante notar que lo mas importante en el diagrama de casos de uso inicialmente es establecer bien las funcionalidades del sistema que posteriormente se convertirn en los casos de uso del sistema, y posterior a ello se observan entes autnomos que realicen dichas funcionalidades y estos sern candidatos a ser actores. En pocas palabras estamos diciendo que se comienza con las funcionalidades. De todas formas, hay ocasiones en las que como no es tan fcil identificar las funcionalidades del sistema se establece una serie de personas y entes autnomos que estn directamente relacionados con el sistema y se observan las funcionalidades que realizan estos entes con el animo de establecer los casos de uso que faltan.
Suponiendo que los casos de uso expuestos en el anterior diagrama ya estn completos procedemos a separarlos y a ha colocar con la figura de un ser humano el ente que posiblemente ejerce dicha funcionalidad en el sistema que estamos desarrollando. Veamos:
funcionario
Solicitud de envio de queja a Empresa Cliente Envio de quejas a la empresa
Captura de quejas del cliente
Almacenamiento de quejas de clientes sistema
Seguimiento de queja expuesta por el Cliente
Evaluacion de quejas no atendidas auditorInterno Evaluacion de quejas atendidas
7.2. TIPOS DE RELACIONES ENTRE LOS CASOS DE USO

Cuando dos casos de uso estn relacionados es porque tienen algo en comn. Si tienen algo en comn pueden existir tres tipos de relaciones:
Relaciones Extends Relaciones Include y Relaciones de generalizacin. En las siguientes secciones se explicaran cada una de estas tres.
7.3. IDENTIFICAR RELACIONES TIPO <<EXTENDS>>

Segn Martin Fowler es importante que se use la relacin de <<extends>> cuando se tenga un caso de uso que es similar a otro, pero que hace mucho ms. No se debe confundir esto con que un caso de uso A implica que se deba hacer algo que hace otro caso de uso B a parte que hace otras cosas. Lo anterior suena bastante confuso, pero es importante que se comprenda, porque si no seria causa de un mal modelamiento. Supongamos los siguientes casos de uso:
Solicitud de envio de queja a Empresa
Cliente
Envio de quejas a la empresa
Y supongamos que al analizar el caso de uso envi de quejas a la empresa, vemos que hay dos tipos de quejas que el cliente puede enviar a la empresa que son: Quejas sobre maltrato fsico Quejas sobre maltrato psicolgico. Y tambin digamos que despus de analizar la situacin, vemos que es necesario hacer la anterior divisin, debido a que los maltratos fsicos son atendidos finalmente por un medico, en tanto que los maltratos psicolgicos son atendidos por un psiquiatra. De otra forma, vemos que tanto los maltratos fsicos como los maltratos psicolgicos tienen unas mismas caractersticas, pero que hacen estas que su atencin sea distinta la una de la otra, pero lo nico cierto es que ambas son quejas de maltrato Con todo lo dicho hasta el momento tenemos pues el siguiente diagrama de casos de uso:
Solicitud de envio de queja
Enviar quejas de maltrato fisico
<<<<extends>>>>
Cliente Envio de quejas <<<<extends>>>> Envia quejas de maltrato psicologico
Observe amigo lector / estudiante que el caso de uso envio de quejas a la empresa no esta directamente relacionado con el actor Cliente. Tambien observe que en trminos lgicos una queja de maltrato fsico es un tipo de queja sobre maltrato y para que esto quede bien claro en el diagrama es necesario colocar la palabra maltrato como se muestra en el siguiente diagrama:
<<<<extends>>>>
Cliente Envio de quejas de maltrato <<<<extends>>>> Envia quejas de maltrato psicologico
Con el anterior diagrama es bueno observar dos cosas: Los casos de uso que extienden del caso de uso base no se colocan directamente relacionados con el actor del sistema. Cuando se dice que un cliente enva quejas de maltrato, se esta diciendo que eventualmente el puede o esta en capacidad de enviar quejas sobre maltrato fsico y de enviar quejas sobre maltrato psicolgico, en pocas palabras se dice que si un actor de hace cargo del caso de uso base, tambin se debe hacer cargo de todas sus extensiones. Una conclusin de las dos anteriores es que si un actor se hace cargo de un caso de uso base, tan solo el se har cargo de todas sus casos de uso que son extensiones del mismo. Segn algunos autores es bueno colocar los verbos de los casos de uso en algn formato, por ejemplo el ms acogido es colocarlos en trminos de verbos en infinitivo, con lo cual nuestro diagrama de casos de uso mejorado seria:
solicitar envio de queja
enviar quejas de maltrato fisico
<<<<extends>>>>
Cliente enviar quejas de maltrato <<<<extends>>>>
enviar quejas de maltrato psicologico
7.4. ERRORES COMUNES CON RELACIONES TIPO <<EXTENDS>>

Segn lo mencionado en la seccin anterior podemos decir que el siguiente diagrama de casos de uso esta mal elaborado.
<<<<extends>>>>
<<<<extends>>>> Cliente Envio de quejas de maltrato
Envia quejas de maltrato psicologico
La razn por la cual esta mal elaborado el anterior diagrama de casos de uso es porque no podemos relacionar los casos de uso que extienden de otro caso de uso directamente con el actor. Veamos ahora el error existente en el siguiente diagrama de casos de uso:
Funcionario
<<<<extends>>>> Enviar quejas de maltrato fisico <<<<extends>>>> Envio de quejas de maltrato Cliente
Envia quejas de maltrato psicologico
El error es que si un actor se hace cargo de un caso de uso base, tambin el se hace cargo de todas las extensiones de dicho caso de uso. En el caso concreto del anterior diagrama vemos que el actor Funcionario se hace cargo de un caso de uso extendido de uno base que esta a cargo del actor Cliente. Es posible que el diagramador quiera hacer el anterior diagrama de casos de uso y se encontrara con que no es posible llevar este diagrama de casos de uso a cdigo. Una opcin para solucionar este problema es crear un caso de uso separado para las quejas de maltrato fsico de los funcionarios. Una posible solucin al anterior problema es la siguiente:
Solicitud de envio de queja a Empresa Enviar quejas de maltrato fisico a clientes
<<<<extends>>>>
<<<<extends>>>> Envio de quejas de maltrato a clientes Envia quejas de maltrato psicologico a clientes <<<<extends>>>> Envio de quejas de maltrato a funcionarios Cliente
Funcionario
Enviar quejas de maltrato fisico a funcionarios
En donde queda claro que se han discriminado los maltratos a funcionarios y los maltratos a clientes. La pregunta que surge entonces es: Cmo optimizar este modelamiento cuando la misma accin sea realizada por varios actores?. Obviamente el modelamiento anterior es bueno cuando no se tengan muchos actores relacionados con envi de quejas sobre maltratos. En trminos de cdigo fuente estaramos diciendo que estaramos escribiendo y duplicando tanto cdigo que el modelamiento no tendra razn de ser si este tipo de situaciones a nivel de implementacin se presentan. Una respuesta posible a la anterior pregunta es que de pronto estemos modelando a un nivel de detalle tan grande que posiblemente ya lo que se este modelando no sean actores y casos de uso, sino mtodos de una clase.
7.5. RELACIONES DE GENERALIZACION SIN ESTEREOTIPO

Hasta el momento las relaciones vistas son relaciones de generalizacin con estereotipo, es decir relaciones de extensin muy controladas con la palabra <<extends>>, pero a veces es importante hacer relaciones de generalizacin menos controladas, por ejemplo en el caso que no se requiera que un actor se haga cargo de todas las extensiones de un caso de uso determinado. Este problema lo vemos en el siguiente caso de uso:
solicitar envio de queja
enviar quejas de maltrato fisico a clientes
<<<<extends>>>>
Cliente enviar quejas de maltrato a <<<<extends>>>> clientes enviar quejas de maltrato psicologico a clientes
<<<<extends>>>> enviar quejas de maltrato fisico a funcionarios enviar quejas de maltrato a funcionarios <<<<extends>>>> enviar quejas de maltrato psicologico a funcionarios Funcionario
<<<<extends>>>> enviar quejas de maltrato fisico a auditores <<<<extends>>>>
enviar quejas de maltrato a auditores
Auditor
enviar quejas de maltrato psicologico a auditores
En donde no es posible agrupar las quejas de maltrato psicolgico y las quejas de maltrato fsico si se sigue usando la palabra <<extends>>. Una solucin es hace relaciones de extensin poco controladas. A fin de comprender como se podra solucionar el agrupamiento en el anterior diagrama de casos de uso, mostramos a continuacin una posible solucin:
enviar quejas de maltrato
enviar quejas de maltrato fisico enviar quejas de maltrato fisico a clientes
enviar quejas de maltrato psicologico
Cliente enviar quejas de maltrato psicologico a clientes enviar quejas de maltrato fisico a funcionarios
enviar quejas de maltrato psicologico a funcionarios
enviar quejas de maltrato psicologico a auditores enviar quejas de maltrato fisico a auditores
Funcionario
Auditor
Observe amigo lector / estudiante que ahora si es posible que casos de uso extendido estn directamente asociados con distintos actores y todo debido a que son relaciones de generalizacin sin estereotipo. Antes de concluir con la explicacin sobre relaciones de generalizacin sin estereotipo decimos algunas afirmaciones sobre este tipo de relaciones:
1. En una relacin de generalizacin sin estereotipo puede anadir o no acciones con respecto al caso de uso base. 2. Un caso de uso extendido por medio de una relacin de generalizacin sin estereotipo es una variante del caso de uso base. 3. En las relaciones de generalizacin sin estereotipo el caso de uso que extiende puede incluir parte o la totalidad del comportamiento del caso de uso base.
7.6. IDENTIFICAR RELACIONES TIPO <<USES>> O <<INCLUDE>>

La razn por la cual la relacin <<uses>> es la misma que la relacin <<include>> es que antiguamente antes de la versin 1.3 de UML se usaba la palabra <<uses>>, pero ahora se usa la palabra <<include>>. A diferencia de las relaciones de generaliacion tanto con estereotipo como con estereotipo <<extends>>, decimos que si un caso de uso A, incluye el comportamiento del caso de uso B, entonces el caso de uso A, esta obligado a incluir todo el comportamiento del caso de uso B. En pocas palabras estamos diciendo que para los casos de uso que tengan una relacin <<include>> como la siguiente:
<<<<include>>>> Caso de USO A Diagrama NO VALIDO
<<<<include>>>> ACTOR Caso de USO X Caso de USO B
No son validos, al igual que tampoco son validos diagramas como el siguiente:
Caso de USO A <<<<include>>>> validar usuario ACTOR <<<<include>>>> Diagrama NO VALIDO
Caso de USO B
En tanto que diagramas como los siguientes si son validos:
<<<<include>>>> Caso de USO A <<<<include>>>> validar usuario ACTOR Diagrama VALIDO Caso de USO B
Y no esta dems recordar que diagramas de casos de uso como los siguientes:
<<<<extends>>>> Caso de USO A Diagrama NO VALIDO
Caso de USO X ACTOR <<<<extends>>>> Caso de USO B
No son validos, en tanto que diagramas como los siguientes:
<<<<extends>>>>
Caso de USO A
Diagrama VALIDO ACTOR Caso de USO X <<<<extends>>>>
Caso de USO B
Son validos. Para resumir estamos diciendo que relaciones entre casos de uso tipo <<include>> son relaciones de dependencia y por tanto la flecha de generalizacin no aplica cuando se encuentre presente este termino en el diagrama de casos de uso.
7.7. EJEMPLO DE RELACION TIPO <<USES>> O <<INCLUDE>>

El siguiente es un ejemplo de un diagrama de casos de uso que usa la relacin tipo <<include>>:
<<<<include>>>> Consultar Cliente <<<<include>>>> validar usuario funcionario Diagrama VALIDO Matricular Cliente
En el que se esta diciendo que para que se pueda consultar un cliente se debe validar el usuario, y tambin se esta diciendo que para matricular un cliente se debe validar el usuario. Recordemos pues que el siguiente diagrama de casos de uso no es valido:
<<<<include>>>> Consultar Cliente
<<<<include>>>> funcionario
validar usuario Diagrama NO VALIDO
Matricular Cliente
7.8. CASO ESPECIAL DE RELACION TIPO <<USES>> O <<INCLUDE>>

Cuando un caso de uso A dependa de otro caso de uso B, es porque muy probablemente el caso de uso A es usado por un actor, pero esto no quiere decir que el caso de uso B, no sea usado directamente por el mismo u otro actor. Veamos el siguiente diagrama de casos de uso para comprender el concepto:
<<<<include>>>> CASO DE USO ABSTRACTO A B
ACTOR
En el anterior diagrama estamos diciendo que el caso de uso B es un caso de uso abstracto porque no es invocado directamente por un actor. En el siguiente diagrama de casos de uso:
ACTOR A
A <<<<include>>>> CASO DE USO CONCRETO
ACTOR B
Tenemos que el caso uso B, es un caso de uso no abstracto o mejor dicho lo que algunos autores llaman caso de uso concreto.
7.9. DOCUMENTACION DE CASOS DE USO

Es importante documentar los casos de uso y para esto es necesario tener en cuenta que un caso de uso no debe ser una actividad atmica que realiza el sistema, sino que debe ser una funcionalidad que el sistema presta y que puede ser iniciada por unos actores. Dicho esto, es claro que un caso de uso por ser una funcionalidad no tan simple tiene posibilidades que no funciones y esto debe ser de alguna manera documentado, tambin es importante notar que para realizar un caso de uso se deben realizar una serie de acciones con una secuencia que deben estar tambin documentadas debidamente con el fin que el flujo de trabajo de anlisis sea lo mas claro posible.
A continuacin se muestra una plantilla sugerida para documentar casos de uso
Numero del caso de uso <<Numero >> Cabecera del caso de uso
<<Nombre del Caso de Uso.>> Ejemplo: Ingresar estudiante <<Id del <<Nombre del requisito funcional>> requisito funcional>> Ejemplo: Requisito numero 44 del documento de requisitos funcionales establecidos en la entrevista 2 hecha al asistente de decanatura de la Facultad Tecnolgica de la Universidad Distrital <<Versin>> <<Numero de versin y fecha>> Ejemplo: Version 1.3 del 14 de abril de 2008 <<Autores>> <<Autor>> Ejemplo: Luis Felipe Wanumen Silva y Juan Carlos Guevara Bolaos Tipo de Caso Abstracto No Abstracto X de USO Fuentes <<Fuente de la versin actual>> Ejemplo: Documento almacenado en http://www.udistrital.edu.co/facultados.tecnologica/document o1.doc Estado del DEFINITIVO documento Evento de <<Nombre del evento de activacin>> Activacin Ejemplo: Cuando un estudiante hace su peticin de ingreso y se comunica con un usuario que esta activo en el sistema y que tiene las facultades para hacer su ingreso, obviamente con la autorizacin de la Decanatura y de la Universidad para realizar el proceso de matricula para dicho estudiante.
<<Objetivo <<Nombre del objetivo general>> general del caso de Ejemplo: uso>> Registrar un estudiante mediante el proceso de matricula para que sea parte activa del sistema y pueda gozar de todos los privilegios acadmicos con que cuenta un estudiante de la Universidad Distrital. <<Objetivos <<Nombre del objetivo especifico>> especficos> > Ejemplo: Matricular a un estudiante a la Universidad Distrital y concretamente a la Facultad Tecnolgica en el proyecto Curricular de Sistematizacin de Datos. Modalidad <<Numero modal en el que los actores o entidades son del caso de afectadas>> Uso Ejemplo: El caso de uso no afecta sino nicamente a un estudiante y para ver afectados a varios estudiantes recin matriculados es necesario realizar el proceso n veces, donde n es el numero de estudiantes a los que se les va a realizar el proceso de matricula. El sistema permite a <<lista de actores>> en <<instante en el que se puede realizar el caso de uso>> <<funcionalidad del caso de uso>>. Ejemplo: El sistema permite a los administradores, profesores y estudiantes con permisos de decanatura, hacer la matricula de estudiantes ingresando los datos personales, econmicos, sociales y acadmicos de los nuevos y futuros estudiantes de la Universidad. <<Listado de actores>> Ejemplo: Administrador, profesor, estudiante Objetivo <<Objetivo en infinitivo>><<elementos que se ven afectados por el verbo incluyendo actores o estados del sistema>>
Descripcin:
Actores
Ejemplo: Registrar en la base de datos un estudiante Precondicio <<Estado(s) de actores y/o entidades preliminares para que se pueda ejecutar nes el caso de uso en cuestin>> Ejemplo: El estudiante no debe estar registrado. Pos <<Estado posterior en el que debe estar un actor o una entidad, despus de condiciones ejecutado el caso de uso>> Ejemplo: Conocer todos los datos del estudiante <<Recuerde que el flujo de eventos debe tener coherencia con el futuro diagrama de secuencia y diagrama de colaboracin y que no debe incluir casos no perfectos o excepcionales>> Paso Accin Responsabl e <<Identifica <<accin a realizar o situacin que produce una <<Actor>>. cin del alternativa, mostrando las alternativas para este Especifican paso>> ultimo caso>> do si es una accin o una respuesta de algn agente del sistema. Ejemplo: Ejemplo: Ejemplo: Si << situacin que produce una alternativa>>, el sistema deber <<accin a realizar>> 1 Digitar todos los datos del estudiante Actividades del Actor Ejemplo: Ejemplo: Ejemplo: 2 Validar formulario 2a. Si se valido correctamente el formulario, el sistema debe mostrar un mensaje de satisfaccin al cliente. 2a. Si se valido correctamente el formulario, el sistema debe enviar los datos al servidor usando el mtodo de autenticacin POST. - --------Invocada por el actor e implementa da por el sistema
Flujo de Eventos o secuencia Normal de acciones.
Ejemplo: 2
Ejemplo: Almacenar los datos en la base de datos
Ejemplo:
Flujos alternos
Situaciones Anormales
Respuesta del Sistema ---------------------------------------------------------------------------------N --------------------------------------1 --------------------------2 ----------------------------------------------------------N --------------------------<<Recuerde que en esta parte de la documentacin se pretende modelar el caso de uso y sus situaciones excepcionales que deben estar completamente acordes con los diagramas de flujo futuros con los que se relaciona este caso de uso y que sern elaborados en el flujo de anlisis y diseo. Tambin es bueno recordar que un caso de uso como mnimo debe tener una situacin excepcional, porque si no tiene casos excepcionales, quiere decir que es demasiado atmico o que le falta modelamiento>>. Tambien recuerde que en muchos lenguajes de programacin las excepciones se codifican con bloques try-catch-finally, es decir que no solamente es necesario colocar la excepcin y el manejo que se le va a dar, sino que en muchos casos es necesario colocar acciones que en forma indiferente de la presentacin de la excepcin siempre se van a efectuar, este es el caso de las instrucciones que van en los bloques finally. Tambmin es bueno tener en cuenta que las excepciones son lanzadas y capturadas por otros actores, entidades o sistemas con el animo de lograr un tratamiento adecuado de las excepciones <<en el caso en el que>><<actor o entidad involucrada>><<estado del actor o entidad>><<predicado acorde con la frase>>, el sistema deber <<accin o acciones a realizar>><<casos de uso y /o acciones correctivas>>. (Esto para cada una de las opciones anormales y / o combinacin de estas). Tener en cuenta que a veces ciertas situaciones excepcionales son excepcionales si estn acompaadas de unos ciertos factores. FINALIZADOR: <<Accion que siempre se va a realizar en forma independiente que se presente o no la excepcion>>. ACTORES ENTIDADES O SISTEMAS QUE RECIBEN LA EXCEPCION. <<Actor, entidad o sistema que es capaz de atrapar la excepcion>> Ejemplo:
1. En el caso en el que un estudiante ya est registrado en la base de datos, pero halla sido ingresado el mismo da de la actualizacin de datos, el sistema deber informarle al usuario que ya existe uno y darle la posibilidad para que cree uno nuevo con los datos ingresados actualmente, pero con distinto identificador NIP (numero de identificacin personal) o tambin le da la opcin para que guarde en un archivo los datos, pero que de ninguna manera los ingrese al sistema con este cdigo. FINALIZADOR: A pesar que el estudiante este o no registrado en la base de datos, de todas formas, siempre se emite un mensaje al final, en el que se muestra al usuario los resultados del ingreso o no ingreso del estudiante al sistema por medio de alertas. ACTORES ENTIDADES O SISTEMAS QUE RECIBEN LA EXCEPCION. Si el estudiante ya esta registrado, se notifica al actor AUDITOR para que el conozca por lo menos el cdigo de los estudiantes a los cuales se les ha hecho intentos varios de ingresarlos en forma duplicada con el animo que este tenga conocimiento de mencionados estudiantes. 2. En el caso en el que un estudiante ya est registrado en la base de datos, pero NO halla sido ingresado el mismo da de la actualizacin de datos, el sistema deber informarle al usuario que ya existe uno y darle la posibilidad para que cree uno nuevo con los datos ingresados actualmente, pero con distinto identificador NIP (numero de identificacin personal) o tambin le da la opcin para que guarde en un archivo los datos, pero que de ninguna manera los ingrese al sistema con este cdigo. FINALIZADOR: A pesar que el estudiante este o no registrado en la base de datos, de todas formas, siempre se emite un mensaje al final, en el que se muestra al usuario los resultados del ingreso o no ingreso del estudiante al sistema por medio de alertas. ACTORES ENTIDADES O SISTEMAS QUE RECIBEN LA EXCEPCION. Se notifica al sistema, se crea un archivo de log o si ya existe se le anade una lnea con la explicacin del error presentado y se le da la posibilidad al usuario que guarde o que no guarde los datos digitados hasta el momento para un posterior ingreso. Esto se hace por medio de una carpeta llamada la carpeta de No Enviados.
Cambios de <<Recuerde que toda accin es accin si cambia el estado de alguna entidad
estado
o de algn actor>>(Las cosas se hacen para transformar el estado de algo o de alguien y si no lo logra no es una accin que tenga una funcionalidad interesante, es decir que de no cambiarse el estado de algo, se podra decir que este caso de uso no es un caso de uso) Ejemplo: El estado del estudiante se cambia de inactivo en el sistema a activo en el sistema. Paso Cota de tiempo Ejemplo: 1 2 Ejemplo: N segundos N segundos
Rendimient o
Frecuencia esperada
<<No de veces>>veces <<unidad de tiempo>>
Importancia <<sin importancia o importancia vital>>. (Recuerde o excluyente) Urgencia <<Puede esperar, hay presin, inmediatamente>>
Comentario <<Comentarios adicionales>> s Periodicidad
8. MODELAMIENTO UML Y SU IMPLEMENTACIN EN JAVA

UML es uno de los lenguajes de modelado ms importantes hoy en da utilizado principalmente para modelar aplicaciones y sistemas orientados a objetos. Por esta razn fundamental es preciso anotar que si el lenguaje a utilizar no presenta caractersticas verdaderamente orientadas a objetos, no es muy claro el poder utilizar en todo su esplendor este lenguaje para modelar sistemas desarrollados con estos lenguajes. Por fortuna la mayora de lenguajes de programacin actuales presentan caractersticas verdaderamente orientadas a objetos e incluso lenguajes como java obligan que se tenga una concepcin muy clara a cerca de lo que es el modelado orientado a objetos, por cuanto desde su concepcin se ha visto como un lenguaje orientado a objetos para la web. Precisamente hablando del lenguaje java, se ha querido tomar este como la base para comprender muchos conceptos de orientacin a objetos y para comprende el modelado orientado a objetos. Es sabido por muchos estudiantes que los libros dedicados a la parte de orientacin de objetos con nfasis en el anlisis y/o en el diseo, carecen de la parte de programacin que aterrice los conceptos all expuestos. De otra parte la mayora de textos de referencia o tutoriales sobre un lenguaje en particular carecen de secciones que expliquen como se podra modelar una aplicacin con dicho lenguaje. En ltimas podemos observar que la parte de programacin y la parte de anlisis y diseo se encuentran verdaderamente aisladas en muchos textos y son pocos los libros y tutoriales que intentan dar una visin en conjunto de estas dos cosas que en s, van de la mano, por cuanto del tipo de lenguaje a utilizar depende del tipo de modelamiento a utilizar. Con todo lo expuesto anteriormente, el autor de la enciclopedia conociendo ha querido desarrollar un material que de las bases generales del lenguaje UML, pero orientando al estudiante sobre la forma de ir de una vez haciendo sus implementaciones en lenguaje java. Se ha tomado el lenguaje java para este fin, por ser uno de los lenguajes ms utilizados en el mundo para la programacin en internet y ltimamente para la programacin de aplicaciones mviles, de voz, de correo, de dispositivos, etc.
8.1. DEFINICIN DE RELACIONES

Las relaciones se pueden definir como el tipo de conexiones entre las diferentes clases necesarias para la implementacin de una aplicacin o de un sistema. Este concepto viene entonces ntimamente ligado con el concepto de relaciones que se ve en el mundo real entre los diversos objetos que se pueden encontrar en el mismo. Por ejemplo un carro es un tipo de automvil y un automvil es a su vez un tipo de medio de transporte y un medio de transporte es a su vez un objeto inventado por el hombre y entre estos conceptos podramos
entonces definir un tipo de relaciones especficas para modelar esta forma de percibir al carro con respecto a otros trminos reales o abstractos inventados por el hombre. Existen a su vez varios tipos de relaciones entre los objetos, las cuales se irn describiendo con mayor detalle en las siguientes secciones, pero por el momento nos limitaremos a decir que las ms importantes son: TIPOS DE RELACIONES
Relaciones de DEPENDENCIA
Relaciones de GENERALIZACIN
Relaciones de ASOCIACIN
8.2. GENERALIZACIN VS HERENCIA

Supongamos el siguiente diagrama de clase:
MATER IA COD_MAT : Integer NOM_MAT : String
ASIGNATURA COD_ASIG : Integer NOM_ASIG : Strin g
La implementacin de dicho diagrama de clase se hace en dos archivos, los cuales se muestran a continuacin:
// Archivo: MATERIA.java public class MATERIA { protected Integer COD_MAT; private String NOM_MAT; MATERIA() { } }
y el archivo:
// Archivo: ASIGNATURA.java public class ASIGNATURA extends MATERIA { private Integer COD_ASIG; private String NOM_ASIG; ASIGNATURA() { }
Observemos que esto es en esencia una herencia simple, debido a que existe una clase base denominada MATERIA y una clase que hereda de sta, la cual se llama ASIGNATURA. En realidad los trminos generalizacin, nos indican que una clase es la base para las dems y el trmino herencia, nos indica que una clase hereda caractersticas de otra, la cual es una clase generalizacin con respecto a la mencionada. En vista de ste tipo de discusiones, podemos ver que en realidad estamos hablando de lo mismo, lo que sucede es que para referirnos a la clase de la que se hereda usamos el trmino generalizacin y para referirnos a la que utiliza dicha clase para heredar, utilizamos el trmino herencia.
8.3. EL ACCESO PRIVADO

Para no ir tan lejos con la parte terica, diremos que una funcin que sea privada en una clase solamente puede ser accedida por otra funcin en la misma clase. Es decir que una funcin privada no puede ser llamada desde una instancia de la clase y mucho menos desde una instancia de una clase heredada de esta. Bueno, con el nimo de ir explicando todos estos conceptos, a continuacin se muestra una clase denominada MATERIA, la cual tiene tres funciones privadas (getCOD_MAT(), getNOM_MAT() y getDES_MAT() ) y una funcin pblica (getCODIGO() ). Veamos:
// Archivo: MATERIA.java public class MATERIA {
protected Integer COD_MAT; MATERIA() { COD_MAT = new Integer(5); } private Integer getCOD_MAT(){ return COD_MAT; } // Por defecto la funcion es publica Integer getCODIGO(){ Integer aux = getCOD_MAT(); return aux; }
Observemos que podemos llamar a la funcin getCOD_MAT() desde una funcin que haga parte de la clase y no ocurre ningn error: Pues bien, si intentramos acceder a la funcin getCOD_MAT() desde una instancia de la clase MATERIA, tal como se muestra a continuacin:
MATERIA obj_materia = new MATERIA(); Integer cod_materia = obj_materia.getCOD_MAT();
Tendramos un error al compilar el programa y este error sera: getCOD_MAT() has private access in MATERIA Integer cod_materia = obj_materia.getCOD_MAT(); 1 error Como se imaginar el amigo lector / estudiante, si no es posible acceder a una funcin como la anterior desde una instancia de la clase, mucho menos ser posible acceder a la funcin desde una clase heredada. Para mostrar este concepto, a continuacin se muestra una clase que hereda de la clase MATERIA, y que se denomina ASIGNATURA, la cual tiene una instruccin que intenta acceder a la funcin getCOD_MAT() y obviamente no puede. Veamos:
// Archivo: ASIGNATURA.java public class ASIGNATURA extends MATERIA { private Integer COD_ASIG; private String NOM_ASIG; ASIGNATURA() { Intege codigo_mat = getCOD_MAT(); }
Para este caso el compilador sacar un error similar al siguiente:
getCOD_MAT() has private access in MATERIA Intege codigo_mat = getCOD_MAT(); 1 errors Yo s que puede sonar bastante canzn y molesto decir que las instancias de la clase heredada tampoco podrn acceder a la funcin getCOD_MAT(), pero por experiencia docente se que es necesario hacer todo este tipo de aclaraciones con el nimo no de repetir cosas, sino de lograr la mayor comprensin de los conceptos. Veamos las siguientes instrucciones:
ASIGNATURA ojb_asignatura = new ASIGNATURA(); Integer cod_asignatura = ojb_asignatura.getCOD_MAT();
De las cuales solamente nos resta decir que generan un error similar al siguiente: getCOD_MAT() has private access in MATERIA Integer cod_asignatura = ojb_asignatura.getCOD_MAT(); 1 errors
8.4. EL ACCESO PROTECTED

El atributo PROTECTED aplicado a un miembro dato, indica que las funciones de la clase base pueden accederlo sin ningn problema, y ms an, que las funciones miembro de las clases derivadas de esta tambin lo pueden acceder. Hay que tener en cuenta que se comportan como si fueran PRIVATE para las funciones miembro de clases que no tengan relacin de herencia con la misma. Conclusin: Lo protegido, no es tan protegido para los hijos, como en la vida real, las personas protegen sus cosas, pero le dan muchas veces confianza de utilizacin de los bienes a los hijos Bueno, a continuacin se muestra una clase base:
// Archivo: MATERIA.java public class MATERIA { protected Integer COD_MAT; private String NOM_MAT; public String DES_MAT; MATERIA() { COD_MAT = new Integer(5); } protected Integer getCOD_MAT(){ return COD_MAT; } // Por defecto la funcion es publica
void setCODIGO(){ COD_MAT =new Integer(20); }
Observemos que esta clase tiene una funcin denominada setCODIGO(), la cual modifica el tipo de objeto de dato llamado COD_MAT. Pues bien, es posible crear una instancia de esta clase y por medio de la misma modificar nuevamente la variable de objeto de dato, tal como se muestra a continuacin:
MATERIA obj_materia = new MATERIA(); obj_materia.COD_MAT = new Integer(35);
Ahora vamos pues a crear una clase heredada de la clase anterior, denominada ASIGNATURA, la cual se muestra a continuacin:
// Archivo: ASIGNATURA.java public class ASIGNATURA extends MATERIA { private Integer COD_ASIG; private String NOM_ASIG; ASIGNATURA() { // Integer codigo_mat = getCOD_MAT(); COD_MAT = new Integer(10); } }
Como podemos observar, esta clase tambin puede modificar el objeto de datos COD_MAT en forma directa, sin mayores problemas. Podemos entonces ver que es factible modificar la misma variable desde una instancia de la clase ASIGNATURA, tal como se muestra a continuacin:
ASIGNATURA obj_asignatura = new ASIGNATURA(); obj_asignatura.COD_MAT = new Integer(30);
8.5. ACCESO A LOS ATRIBUTOS: PRIVATE, PROTECTED O PUBLIC

A los diversos atributos se les puede colocar tres palabras reservadas que los preceden con el fin de especificar el tipo de acceso que se va a tener de los mismos desde otras clases. A continuacin se presenta un cuadro en el que se muestra el tipo de acceso que se tiene a un atributo si se declara como private, protected o public. Acceso desde: la propia clase private protected public (package) S S S S
subclase en el mismo paquete otras clases en el mismo paquete subclases en otros paquetes otras clases en otros paquetes
N N N N
S S X N
S S S S
S S N N
En este cuadro la S, significa: Puede acceder N: No puede acceder. X: puede acceder al atributo en objetos que pertenezcan a la subclase, pero no en los que pertenecen a la clase madre. Es un caso especial
8.6. ASOCIACIONES
Las asociaciones son uno de los temas ms tratados en bases de datos y la verdad es que es necesario tratar este tema con mucho cuidado y detenimiento, puesto que de nada sirve crear y estructurar bien las clases, si la asociaciones entre las mismas no se hacen de la mejor forma. En el siguiente ejercicio, se muestra la asociacin entre una ASIGNATURA y un ESTUDIANTE:
+tomada_por ASIGNATURA COD_ASIGN : Integer NOM_ASIGN : String 0..6 INSCRIPCION +inscribe 0..35 ESTUDIANTE COD_ESTU : Integer NOM_ESTU : String
En el anterior diagrama de clases, se est intentando decir: Un estudiante puede inscribir o no una materia Un estudiante puede inscribir como mximo seis materias Una asignatura puede estar asociada con un cero o hasta 35 estudiantes El nombre de la asociacin entre el objeto ASIGNATURA y el objeto ESTUDIANTE es INSCRIPCIN, debido bsicamente a que una asignatura es inscrita por un ESTUDIANTE y un estudiante inscribe una ASIGNATURA.
Es importante reconocer que a simple vista las asociaciones permiten la comunicacin y el paso de informacin entre un objeto y otro, pero no por ello se debe estar de acuerdo con las personas que argumentan que las asociaciones violan el principio de encapsulacin de informacin propio de la programacin orientada a objetos. Esto lo digo porque es probable que una asociacin tenga atributos inherentes a sta que no se puedan adjudicar directamente a cualquiera de las clases involucradas.
Pero bueno, veamos en primera medida la solucin al diagrama anterior:

// Archivo: ASIGNATURA.java public class ASIGNATURA { private Integer COD_ASIGN; private String NOM_ASIGN; public ESTUDIANTE inscribe[]; ASIGNATURA() { }
// Archivo: ESTUDIANTE.java public class ESTUDIANTE { private Integer COD_ESTU; private String NOM_ESTU; public ASIGNATURA tomada_por[]; ESTUDIANTE() { }
8.7. LAS AGREGACIONES

Se dice que entre dos objetos hay una relacin de agregacin cuando uno es parte de otro. En general la relacin de agregacin es un tipo de asociacin pero ms fuerte, dado por el carcter de una relacin de composicin de algo en partes que son otras clases. Para comprender estos conceptos, a continuaciones muestra un ejemplo con las partes de un computador. Veamos:
MONITOR C OD_MON : Integer +muestra NOM_MON : String
CPU COD_CPU : Integer NOM_CPU : String +procesa
MUESTRA +en 1..1 via2 +envia1 COMPUTADOR C OD_COMP : Integer NOM_C OMP : String +envia3 TECLADO COD_TECL : Integer NOM_TECL : String MANIPULA
PROCESA
+envia4 IMPRIME +imprime IMPRESORA CO_IMPR : Integer NOM_IMP : String
+manipula
La implementacin del anterior diagrama se muestra a continuacin en donde se especifica el contenido y el nombre de cada archivo de java que es necesario crear para implementar el anterior diagrama:
// Archivo: COMPUTADOR.java public class COMPUTADOR { private Integer COD_COMP; private String NOM_COMP; public MONITOR muestra; public TECLADO manipula; public CPU procesa; public IMPRESORA imprime[]; COMPUTADOR() { }
Un COMPUTADOR est relacionado con cero a un monitor por medio del rol muestra. Un COMPUTADOR est relacionado con cero o una CPU por medio del rol procesa
Un COMPUTADOR est relacionado con cero o un TECLADO por medio del rol manipula. Un COMPUTADOR est relacionado con cero o varias EMPRESORAS
// Archivo: CPU.java public class CPU { private Integer COD_CPU; private String NOM_CPU; public COMPUTADOR envia2; CPU() { }
Una CPU, est relacionada con uno y con slo un COMPUTADOR por medio del rol envia2
// Archivo: IMPRESORA.java public class IMPRESORA { private Integer CO_IMPR; private String NOM_IMP; public COMPUTADOR envia4; IMPRESORA() { }
Una IMPRESORA, est relacionada con cero o un COMPUTADOR por medio del rol envia4
// Archivo: MONITOR.java public class MONITOR { private Integer COD_MON; private String NOM_MON; public COMPUTADOR envia1; MONITOR() { }
Un MONITOR est relacionado con cero o un COMPUTADOR, por medio del rol envia1
// Archivo: TECLADO.java public class TECLADO { private Integer COD_TECL; private String NOM_TECL; public COMPUTADOR envia3;
TECLADO() { } }
Un TECLADO est relacionado con cero o un COMPUTADOR por medio del rol envia3
8.8. RELACIONES DE DEPENDENCIA
NOTA COD_NOTA : Integer VALOR_NOTA : Integer DESCRIPCION : String
0..n
CALIFICACION
ESTUDIANTE COD_ESTU : Integer NOM_ESTU : String
1..1
Los archivos en java que implementan el anterior diagrama son:

// Archivo: ESTUDIANTE.java public class ESTUDIANTE { private Integer COD_ESTU; private String NOM_ESTU; public NOTA tomada_por[]; ESTUDIANTE() { } }
// Archivo: NOTA.java public class NOTA { private Integer COD_NOTA; private Integer VALOR_NOTA; private String DESCRIPCION; public ESTUDIANTE inscribe[]; NOTA() {
Observemos que los valores que determinan la cardinalidad se pueden especificar ms adelante a medida que se vayan creando los diversos objetos. A las dependencias en muchas ocasiones se les conoce como relaciones de uso y esto se debe a que son utilizadas comnmente para especificar que una clase utiliza a otra para realizar determinadas operaciones y obviamente la clase que usa a la otra es una clase que depende de la inicial. En trminos grficos, la situacin se puede comprender de la siguiente manera:
COORDINACIN
COORDINADOR
Dependencia Un cambio en el coordinador afecta a la coordinacin, es decir la coordinacin depende del coordinador. (Bueno, en la vida real, la coordinacin depende tambin de muchos otros elementos y de muchas clases como se dira en programacin orientada a objetos). La situacin anterior, indicara por tanto, alguna de las siguientes situaciones: o Existe una funcin en la clase COORDINACIN que utiliza un objeto de tipo COORDINADOR para realizar alguna operacin. o Existe una funcin que recibe un parmetro por valor en la clase COORDINACIN, que es una instanciacin de la clase COORDINADOR.
8.9. HERENCIA MLTIPLE EN JAVA

La herencia mltiple en java no est permitida. En trminos sencillos la herencia mltiple hace referencia a la capacidad de una clase de heredar de dos o ms clases.
9. ESTEREOTIPOS DE LAS CLASES EN UML 2.0

Los estereotipos de las clases son distintos a los tipos de clases. En esta seccin se muestran los estereotipos de las clases segn la versin 2.0 de UML. No existen mas estereotipos, con lo cual si se colocan estereotipos distintos se podra hacer a menos que se especifique en alguna parte del documento que estn haciendo extensiones al lenguaje UML, que esto es valido, pero siempre y cuando se especifique en el documento.
9.1. LAS CLASES CON ESTEREOTIPO VIEW

Clases como la siguiente:
ConsultaEstudiantesEx celentes
Son clases consulta. Es decir que se estn relacionadas con consultas a bases de datos que se hacen en el sistema. La anterior tabla tambin se pude modelar como se muestra a continuacin:
<<<<View>>>> ConsultaEstudiantes Excelentes
9.2. LAS CLASES CON ESTEREOTIPO TABLE

Clases como la siguiente:
Estudiante
Son clases tabla. Es decir que estas clases tienen su equivalente en una base de datos y son clases que manipulan la informacin de una tabla de una base de datos. Tambin se puede dibujar la anterior clase de la siguiente forma:
<<<<Table>>>> Estudiante
9.3. LAS CLASES CON ESTEREOTIPO SERVICE

La siguiente clase es una clase tipo Service.
Estudiante
Se usa cuando se quiere modelar una clase que globalice un servicio. Esto puede ser til tanto en la parte del modelo del dominio como en cualquier diagrama de clases de anlisis o de diseo. De forma anloga a las anteriores clases, es posible diagramar la clase con la convencin que siempre usamos para las clases que es un cuadro dividido en tres secciones, pero adicionndole la etiqueta <<service>>.
<<<<Service>>>> Estudiante
9.4. LAS CLASES CON ESTEREOTIPO RESOURCE

Se usan para especificar que guardan relacin estrecha con un recurso o para especificar que manipulan algn recurso. Se pueden diagramar as:
Estudiante
O tambin se pueden diagramar as:
<<<<Resource>>>> Estudiante
9.5. OTROS ESTEREOTIPOS DE CLASES

En la siguiente tabla resumimos los diversos estereotipos de clases que faltan por explicar y hacemos un breve comentario de su uso. FORMA DIAGRAMAR LA CLASE SIN EL ESTEREOTIPO FORMA DE DIAGRAMAR LA CLASE CON EL ESTEREOTIPO BREVE EXPLICA CION
Trabajador <<<<Physical Worker>>>> fsico Estudiante
Estudiante
<<<<Location>>>> Edificio
Clase que especifica una localizaci n
Edificio
<<<<Interface>>>> Edificio Edificio
Interface
<<<<entity>>>> Edificio
Entity. Especifica que es una
entidad.
Edificio
<<<<Domain>>>> Mundo
Mundo
<<<<control>>>> Mundo
Domain. Generalme nte son clases que aparecen en el dominio del problema. Control
Mundo
Business <<<<Business Worker>>>> Worker Mundo
Mundo
<<<<Business Goal>>>> Mundo
Business Goal. Meta de negocio
Mundo
<<<<Business Event>>>> Business Event. Mundo
Evento de negocio.
Mundo
<<<<Business Entity>>>>Business Entity. Mundo
Entidad e negocio.
Mundo
Business <<<<Business Document>>>> Document. Mundo Document o de negocio

Mundo
<<<<Business Actor>>>> Business Actor. Mundo
Actor de negocio
Mundo
<<<<boundary>>>> Mundo Mundo
Boundary
<<<<Actor>>>> Mundo Mundo
Actor. Esta clase es mas comnmen te modelada con la figura similar a la humana
10. P.O.O. EN JAVA Y CLASES ABSTRACTAS
10.1. LAS CLASES ABSTRACTAS

TIPO DE CLASE abstract interface COMO UTILIZARLA Extends implements
Las clases tipo abstract, son clases que describen como se tienen que declarar los mtodos, sin tener que implementarlos. Es ms, si los mtodos son declarados abstract en una clase abstract, es porque no pueden ser implementados en la misma clase, sino en una clase que herede de la misma. Otra cuestin bien importante a tener en cuenta es el hecho que una clase que herede de una clase tipo abstract, est obligada a implementar todos los mtodos que la clase antecesora en cuestin tenga definidos como de tipo abstract. Para lograr que el amigo lector / estudiante comprenda estos conceptos a continuacin se muestra un ejercicio que muestra dos archivos en cada uno de los cuales hay una clase. Estos archivos describen en forma sencilla la forma de crear una clase abstracta y la forma de utilizarla. Veamos:
// Archivo: uml1.java package uml2; import java.awt.*; import java.awt.event.*; public abstract class uml1 { public abstract void printf(); }
// Archivo: MyApp.java package uml2; import java.awt.*; import java.awt.event.*; public class MyApp extends uml1{ public void printf(){ System.out.println("probando"); } }
Observe el amigo lector que la implementacin del mtodo printf() es obligatoria en la clase MyApp
10.2. CASO 1: SOBRE LAS CLASES ABSTRACTAS

Veamos el siguiente programa que genera un error:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public int estatura(){ return 5; } } } padre obj_padre = new padre(); // Cierra public class MyApp
El error dependiendo el compilador java es algo similar al siguiente: MyApp.padre is abstract; cannot be instantiated padre obj_padre = new padre(); 1 error Exit code: 1 There were errors
Las clases abstractas no pueden ser instanciadas directamente, pues fueron creadas para que otras hereden de ellas y stas ltimas si pueden ser instanciadas.

El siguiente programa es totalmente vlido. Veamos:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{
} public class hijo extends padre{ } hijo obj_hijo = new hijo(); } // Cierra public class MyApp
public int estatura(){ return 5; }
Una clase no abstracta que herede de una clase abstracta puede ser instanciada directamente

Observemos el siguiente programa:
import java.applet.*; public class MyApp extends Applet { public abstract class bisabuelo{ public int estatura(){ return 5; } } public class abuelo extends bisabuelo{ } public abstract class padre extends abuelo{ } public class hijo extends padre{ } public abstract class nieto extends hijo{ } abuelo obj_abuelo = new abuelo(); hijo obj_hijo = new hijo(); } // Cierra public class MyApp
El programa anterior es totalmente vlido debido a que la clase bisabuelo es una clase abstracta, pero su funcin estatura() no lo es, lo que quiere decir que una clase que herede de la clase bisuabuelo, no est obligada a implementar el mtodo estatura(). De otra
parte la clase abuelo hereda de bisabuelo y no por ello est obligada a ser una clase abstracta. En ltimas vemos que el rbol de herencia puede seguirse prolongando hasta que no aparezca el identificador final (el cual se explicar ms adelante.). Por ltimo vemos que las nicas clases que se estn instanciando directamente son las clases abuelo e hijo, quienes no son abstractas y por lo tanto es perfectamente vlido instanciarlas.
Una clase abstracta puede heredar de una abstracta o de una no abstracta. Una clase no abstracta puede heredar de una clase abstracta o de una no abstracta.

Observemos el siguiente ejercicio:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public int estatura(){ return 161; // cm } } public abstract class madre{ public int estatura(){ return 154; // cm } } public class hijo extends padre extends madre{ } // Cierra public class MyApp
El programa anterior genera un error, debido a que no es posible hacer una clase que herede de dos clases abstractas. El error que genera al anterior programa al compilarlo es similar al siguiente: '{' expected public class hijo extends padre extends madre{
Aunque muchos compiladores no colocan explcito el error de intentar heredar simultneamente de dos clases mediante la palabra reservada extends, es importante tener en cuenta que no es posible heredar de dos clases abstractas al mismo tiempo debido a que por este mecanismo no se permite la herencia mltiple.

Observemos el siguiente programa que define una clase abstracta denominada padre:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract int estatura(){ return 161; // cm } } } // Cierra public class MyApp
Como podemos observar en este programa, se crea una clase abstracta llamada padre, la cual define un mtodo que devuelve un valor entero y dicho mtodo se llama estatura(), el error surge porque se estn abriendo y cerrando corchetes despus del mtodo lo cual estara indicando que se va a implementar dicho mtodo y recordemos que los mtodos abstractos de una clase abstracta no se pueden implementar en dicha clase, sino en las clases que hereden de la misma. Algunas personas piensan que el error surge porque se estn colocando instrucciones dentro del mtodo. Pues para las personas que piensan esto, veamos el siguiente programa:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract int estatura(){ } } } // Cierra public class MyApp
Vemos entonces que este programa tambin genera errores, y eso que no hay nada de instrucciones en medio de los corchetes. La razn es muy sencilla a pesar de no tener instrucciones en dicho mtodo el solo hecho de colocar corchetes le est indicando a java que es posible colocar instrucciones y esto provoca un error.
En los dos programas anteriores mostrados se presenta pues el mismo error, el cual es algo similar al siguiente: abstract methods cannot have a body public abstract int estatura(){
Las clases abstractas no pueden contener instrucciones y es ms, ni siquiera deben tener corchetes de apertura y cierre, sino nicamente la sola definicin (no declaracin) del mtodo seguido por un punto y coma.
Para corregir el problema presentado en los dos anteriores programas se muestra un programa que declara el mtodo abstracto en una clase abstracta pero que no da pie para su definicin y mucho menos su implementacin. Veamos:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract int estatura(); } } // Cierra public class MyApp

Observemos detenidamente el siguiente programa:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract int estatura(); } public class hijo extends padre{ } // Cierra public class MyApp
El anterior programa define una clase abstracta denominada padre, la cual tiene un mtodo abstracto llamado estatura(). El problema con este programa radica no en la clase padre, sino en la clase hijo, la cual hereda de la clase padre, pero no implementa el mtodo abstracto estatura() proveniente de su clase ancestra.
Por todo lo anterior a continuacin se muestra el error generado por java al compilar el anterior programa: MyApp.hijo should be declared abstract; it does not define estatura() in MyApp.padre public class hijo extends padre{
Si una clase no abstracta hereda de una clase abstracta y dicha ancestra declara mtodos abstractos, es obligacin de la clase no abstracta definir los mtodos abstractos de sus clases antecesoras.
Para corregir el problema del programa anterior, a continuacin se muestra la nueva definicin de la clase hijo para lograr que el programa no tenga errores. Veamos:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract int estatura(); } public class hijo extends padre{ public int estatura(){ return 165; // cm } } // Cierra public class MyApp
Es bueno que el amigo lector y/o estudiante tenga en cuenta que al definir el mtodo abstracto en la clase que hereda de la clase abstracta se omite la palabra abstract en el mtodo y el resto se deja igual. Tambin es bueno que se tenga en cuenta que el abrir y cerrar corchetes en el mtodo estatura() de la clase hijo es supremamente importante. Algunos estudiantes han preguntado si es obligatorio que se coloquen instrucciones en el mtodo estatura() del programa anterior. La respuesta es que no. Y para comprobarlo, puede compilar el siguiente programa que no genera ningn error y que sintcticamente es correcto. Veamos:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract void saludo(); } public class hijo extends padre{
public void saludo(){ } } } // Cierra public class MyApp
Pero bueno, obviamente para lograr que esto funcionase, hubo necesidad de cambiar la declaracin del mtodo saludo() de la clase padre, con el nimo de lograr que dicho mtodo no devolviera un valor entero, porque el hacerlo obligara a que al momento de definir el mtodo saludo() en la clase hija fuera necesaria la instruccin return y de lo que se trataba era de mostrar que era posible definir mtodos en la clase hijo que no tuvieran instrucciones algunas en medio de los corchetes de apertura y cierre de la funcin saludo().

import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public abstract void saludo(); } public abstract class hijo extends padre{ public abstract void saludo1(); } public class nieto extends hijo{ public void saludo1(){ } public void saludo(){ } } // Cierra public class MyApp
En el anterior programa no se presenta error alguno, debido a que las clases abstractas pueden declarar mtodos, y no estn obligadas a declarar mtodos abstractos de sus clases abstractas ancestras. Por ejemplo para este caso, la clase hijo declara un mtodo abstracto llamado saludo1() y no est obligada a declarar el mtodo abstracto saludo(), por ser sta clase hija una clase tambin abstracta. De otra parte la clase llamada nieto como no es clase abstracta, est obligada a definir (no declarar) el mtodo abstracto saludo1() de la clase hijo y adems est obligada a definir el mtodo abstracto saludo() de la clase padre, por ser una clase que implcitamente hereda de esta tambin.
Recordemos que si C hereda de B y B hereda de A, implcitamente C hereda de A. Esto se podra pensar como una ley de transitividad en la herencia, pero bueno, no es el tema hablar en trminos matemticos de estos aspectos. Por lo pronto basta con que se entienda que para nuestro ejercicio, la clase nieto hereda implcitamente de padre.
Las clases abstractas que hereden de otras clases abstractas pueden o no declarar mtodos que tengan el mismo nombre y parmetros de sus clases abstractas antecesoras

import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public int estatura(); } } // Cierra public class MyApp
Este programa genera un error similar al siguiente: missing method body, or declare abstract public int estatura(); La razn es que la clase abstracta padre posee un mtodo llamado estatura(), el cual no es abstracto y por tanto no solamente debe declararse, sino definirse.
Los mtodos que no sean abstractos y que se encuentren en clases abstractas deben definirse y no solamente declararse.
Para corregir el problema del programa anterior, se podra definir el mtodo estatura() tal como se muestra en el siguiente programa:
import java.applet.*; public class MyApp extends Applet { public abstract class padre{ public int estatura(){ return 165; }; } } // Cierra public class MyApp
11. P.O.O. EN JAVA Y LAS INTERFACES

Como decamos en secciones anteriores: TIPO DE CLASE Abstract Interface COMO UTILIZARLA Extends implements
Una clase tipo abstract describe como se tienen que declarar los mtodos, sin tener que implementarlos, pero tengamos en cuenta que la clase que va a implementar estos mtodos es una clase que hereda de la clase abstract. En cambio cuando se declara una clase como de tipo interface y es utilizada por otra por medio de la instruccin implements, estamos dijramos copiando los mtodos de la clase interfaz a la clase que la implementa. Con ello, estamos pues evitando el problema de tener que heredar y esto obviamente ser muy til cuando veamos la necesidad de heredar de varias clases, no haremos esto, sino simplemente crearemos varias clases tipo interfaz y otras clases sern las que implementan la funcionalidad de las anteriores y as evitaremos el gran problema que describamos en apartados anteriores: El problema que java no permite la herencia mltiple. Bien, y ahora con el nimo de lograr que el amigo lector / estudiante adquiera la destreza para crear este tipo de clases, a continuacin se muestra un ejercicio que tiene dos archivos cada uno con una clase, en donde habr una clase que es de tipo interface y otra que la implementa. Veamos:
// Archivo: MyApp.java package uml2; import java.awt.*; import java.awt.event.*; class MyApp implements uml1{ public void printf(){ System.out.println("probando"); } }
// Archivo: uml1.java package uml2; import java.awt.*; import java.awt.event.*; public interface uml1 { public void printf(); }
11.1. LAS INTERFACES DEBEN INICIALIZAR SUS ATRIBUTOS

El siguiente cdigo es correcto
// Esta clase no genera error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte
Debido a que inicializa el valor de las variables posicin_x y posicin_y con los valores 2 y 0 respectivamente Pero con el nimo de lograr la mayor comprensin de este tema, por parte del estudiante a continuacin se muestra un ejemplo que genera un error. Veamos:
// ESTA CLASE GENERA UN ERROR public interface transporte{ public int posicion_x; public int posicion_y; } // Cierra interface transporte
La razn por la que genera un error es debido bsicamente a que en una interfaz se necesita que se le asigne un valor a cada una de las variables que se declaren en dicha clase.
11.2. EN LAS INTERFACES NO ES OBLIGATORIO MODIFICADORES DE ATRIBUTOS

En las clases tipo interface, no es obligatorio colocar el modificador de cada uno de los atributos de una clase. Para mostrar este concepto a continuacin se muestra una clase en la cual se tiene un primer atributo denominado posicin_x con modificador y otro atributo denominado posicin_y sin modificador. Veamos pues:
// Esta clase no genera un error public interface transporte{ public int posicion_x=2; int posicion_y=0; } // Cierra interface transporte
11.3. EL MODIFICADOR DE ATRIBUTO POR DEFECTO ES PUBLIC EN LAS INTEFACES

En el siguiente cdigo:
// Esta clase no genera un error public interface transporte{ public int posicion_x=2; // declara posicion_y como public int posicion_y=0; } // Cierra interface transporte
Se deja en claro que el modificador por defecto en las interfaces es public.
11.4. EL MODIFICADOR DE ATRIBUTO PROTECTED NO ESTA PERMITIDO EN LAS INTERFACES

En las interfaces se tiene una limitacin en cuanto al modificador permitido para los atributos de dicha clase, por cuanto no se permite el modificador protected. A continuacin se muestra una clase que genera un error por cuanto define un atributo con el modificador protected. Veamos pues:
// ESTA CLASE GENERA UN ERROR
public interface transporte{ public int posicion_x=2; // genera error por tener el // modificador protected protected int posicion_y=0; } // Cierra interface transporte
11.5. EL MODIFICADOR DE ATRIBUTO PRIVATE NO ESTA PERMITIDO EN LAS INTERFACES

Otra limitacin importante de las interfaces es que no permiten la declaracin de atributos con el modificador private. Veamos entonces una clase que incurre en este error y que por tanto no permite que la aplicacin por lo menos compile:
// ESTA CLASE GENERA UN ERROR public interface transporte{ public int posicion_x=2; // genera error por tener el // modificador private private int posicion_y=0; } // Cierra interface transporte
para corregir el problema necesitaramos cambiarle el modificador private por el modificador public o de otra manera tambin podramos quitarle el modificador debido a que como se mencionaba anteriormente el modificador por defecto para los atributos de una interfaces es pblico, con lo cual el quitarle el atributo bastara para solucionar el problema de compilacin.
11.6. UNA INTERFAZ NO PUEDE SER INSTANCIADA DIRECTAMENTE

El trmino instanciacin hace referencia a la posibilidad de crear objetos a partir de una clase, en este caso, a partir de una interfaz. Diremos entonces que no pueden existir objetos que se creen directamente a partir de una interfaz. El siguiente ejemplo muestra un error debido bsicamente a sta situacin:
/* Autor: Tipo:
Luis Felipe Wanumen Silva Orientacin a objetos
Clase: Descripcin:
*/ import java.awt.*; import java.awt.event.*;
Interface Manipulacin de clases tipo interface
public class MyApp extends Frame { public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); // Aqui el compilador genera error porque // NO PUEDE INSTANCIAR LA INTERFACE // transporte transporte zorra = new transporte(); } }
11.7. UNA CLASE NO INTERFAZ PUEDE IMPLEMENTAR UNA CLASE INTERFAZ

Recordemos que la implementacin es un concepto anlogo a la herencia, en cuanto a que se aplica a la forma en la que una clase puede heredar cuestiones establecidas en una clase base tipo interface. De otra parte, es bueno tener en cuenta que la clase que implementa la clase interface no necesita ser necesariamente interface. El siguiente ejemplo ilustra un caso de xito en el que se define una clase denominada transporte tipo interface y una clase vaca que no es de tipo interface, pero que implementa una clase tipo interface y este programa segn lo mencionado hasta el momento no genera ningn error. Veamos entonces el ejemplo:
/* Autor: Tipo: Clase: Descripcin:
Fecha: */ import java.awt.*; import java.awt.event.*;
Luis Felipe Wanumen Silva Orientacin a objetos Interface Manipulacin de clases tipo interface 9 de Mayo de 2005
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // Esta clase se crea correctamente public class vaca implements transporte{ } // Cierra class vaca public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); // YA NO HAY ERROR AL CREAR EL OBJETO vaca pintada = new vaca(); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); }
11.8. UNA CLASE INTERFAZ NO PUEDE IMPLEMENTAR UNA CLASE INTERFAZ

Recordemos que cuando una clase implementa una clase interfaz, lo que se est diciendo implcitamente es que se contrae una obligacin con la clase tipo interfaz. Dicha obligacin consiste en el compromiso de implementar los mtodos de la clase interfaz en la clase que la implementa. En otras palabras, la clase interfaz dice qu mtodos se deben implementar
o desarrollar en las clases que implementen dicha clase. De otra parte una clase interfaz, no desarrolla mtodos, con lo cual no es posible que una clase interfaz implemente otra clase interfaz debido a que de una la responsabilidad de implementar los mtodos le queda restringida por el simple hecho de ser la clase tambin una clase interfaz. A continuacin se muestra un ejemplo en el que se un error debido a que se infringe con sta norma de programacin en java. Veamos:
/* Autor: Tipo: Clase: Descripcin: Luis Felipe Wanumen Silva Orientacin a objetos Interface Manipulacin de clases tipo interface 9 de Mayo de 2005
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // ESTA CLASE NO SE PUEDE CREAR // debido a que una interfaz no puede // implementar otra interfaz public interface vaca implements transporte{ } // Cierra class vaca public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); }
En caso de ser necesario que una clase interface adquiera la funcionalidad especificada en otra clase tipo interfaz, se puede observar el siguiente tem que muestra como se solucionara ste problema.
11.9. UNA CLASE INTERFAZ PUEDE EXTENDER DE UNA CLASE INTERFAZ

En el tem anterior, se tena un problema tenaz, cuando una clase interface intentaba implementar otra clase interface. Pues bien, ahora se plantea la solucin a ste tipo de problemas, y esto se hace diciendo en primera medida que una clase interface puede extender de una clase interface. Para aclarar este punto, veamos en primera medida el ejemplo:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // Esta clase se puede crear puesto que // UNA INTERFAZ PUEDE EXTENDER DE OTRA // interfaz public interface vaca extends transporte{ } // Cierra class vaca public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show();
Cuando se dice que una clase extiende, quiere decir que la clase hija adquiere la funcionalidad de la clase padre y en este caso la clase padre es una clase tipo interface, con lo cual la clase hija al extender dicha funcionalidad lo puede hacer debido a que ella misma tambin es una clase interface.
11.10. UNA CLASE NO INTERFAZ PUEDE IMPLEMENTAR VARIAS CLASES TIPO INTERFAZ
En ocasiones se hace necesario que una clase implemente la funcionalidad especificada en ms de una clase y esto es perfectamente vlido en java, con lo cual se puede dar un simulacro de herencia mltiple a nivel de interfaz. A continuacin se muestra un ejemplo en el que se tiene una clase denominada vaca que implementa de dos clases tipo interface denominadas transporte y animal. Veamos el ejercicio:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // Esta clase no genera un error public interface animal{ public String tipo="mamifero"; } // Cierra interface animal public class vaca implements transporte, animal{ } // Cierra class vaca public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose();
System.exit(0);
}); // NO HAY PROBLEMA CREANDO OBJETO PINTADA vaca pintada = new vaca();
public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); } }
Es importante notar que en el ejercicio anterior se cre un objeto denominado pintada que es un objeto de tipo vaca, la cual a su vez es una clase que implementa de las interfaces transporte y animal. Recordemos que se pueden crear objetos directamente de clases que no sean interface, pero indirectamente el objeto vaca tiene pues la funcionalidad de las interfaces. Esto es lo que se conoce como herencia mltiple en java, pero si el amigo lector / estudiante observa con cuidado podr descubrir que no existe como tal la verdadera herencia mltiple, debido a que no se pueden heredar implementaciones de mtodos de varias clases y esto en vez de ser una limitacin del lenguaje java a veces se convierte en un gran beneficio a la hora de programar, aunque cuando se comienza con el mundo de la programacin pareciera ser una desventaja.
11.11. UNA CLASE INTERFAZ PUEDE EXTENDER DE VARIAS CLASES TIPO INTERFAZ
Aunque suene un poco raro, es importante no dejarse confundir con sta parte del manual, debido bsicamente a que se podra pensar que dado que en java no se permite la herencia mltiple pura en su concepcin ms amplia, y dicha herencia se realiza mediante la palabra reservada extends, podramos deducir que la extensin de varias clases, si no se permite en otros contextos, no se debera permitir en ste. La verdad es que este es un caso muy especial y tiene que ver con el simple hecho que el compilador verifica si las clases que extienden de una clase tipo interface son clases tipo interface lo permite, y en caso contrario no lo permite. El significado de extender de varias clases tipo interfaz, no quiere decir que se est heredando, sino que se hace un compromiso de implementar los mtodos declarados en las clases interfaces de las que se extiende. Veamos un ejemplo en el que se muestra una clase tipo interface denominada vaca que extiende de dos clases tipo interface denominadas transporte y animal:
/* Autor: Tipo: Luis Felipe Wanumen Silva Orientacin a objetos
Clase: Descripcin:
Interface Manipulacin de clases tipo interface 9 de Mayo de 2005
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // Esta clase no genera un error public interface animal{ public String tipo="mamifero"; } // Cierra interface animal // ESTA CLASE NO GENERA UN ERROR public interface vaca extends transporte, animal{ } // Cierra class vaca public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); } }
11.12. UNA CLASE NO INTERFAZ NO PUEDE EXTENDER DE UNA CLASE TIPO INTERFAZ
En este punto se hace hincapi en el anlisis que hace el compilador de java al verificar que se puede extender de una clase tipo interface o de varias clases tipo inteface siempre y cuando la clase que extienda la funcionalidad de stas sea una clase tipo no interface, de lo contrario no. La razn es bien sencilla y radica en el hecho principal de saber que para poder extender es porque se tiene la garanta que tendr un comportamiento similar a la
clase padre y este comportamiento similar a la clase padre, no se puede asegurar cuando la clase que la extiende no es una clase tipo interface, por cuanto puede tener comportamientos que no corresponden con una clase tipo interface y esto daara o deteriorara el concepto de la extensin de clases. El ejemplo siguiente muestra un programa que genera un error, debido a que se viola el concepto anteriormente explicado:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // ESTA CLASE GENERA UN ERROR // POR CUANTO UNA CLASE NO INTERFACE // NO PUEDE EXTENDER NI DE UNA, NI // MUCHO MENOS DE VARIAS CLASES TIPO // INTERFACE public class vaca extends transporte{ } // Cierra class vaca public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); }
11.13. NO SE PUDE MODIFICAR VARIABLE DE UNA CLASE TIPO INTERFAZ

Es importante tener en cuenta que las variables en una clase tipo interface son tomadas como variables final, con lo cual cualquier intento por modificarlas generar un error inmediatamente. A continuacin se muestra un programa que incurre en este error:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; } // Cierra interface transporte // Esta clase no genera un error public class animal implements transporte{ public String tipo="mamifero"; } // Cierra interface animal public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); // El objeto se crea correctamente animal vaca = new animal(); // No se puede asignar valor a variable // de tipo final vaca.posicion_x = 3;
public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); } }
En el anterior ejemplo, vemos que la variable posicin_x es una variable que pertenece a la interfaz transporte y por lo tanto es como si se hubiese declarado de tipo final, con lo cual cualquier intento por modificar su valor generara un error por parte del compilador, incluso si el valor que se le quisiese asignar fuere el mismo valor que tuviese en la declaracin de la clase. El siguiente ejemplo tambin presenta problemas y no se puede compilar:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; public void moverse(); } // Cierra interface transporte // Esta clase no genera un error public class animal implements transporte{ public String tipo="mamifero"; public void moverse(){ // Esta asignacin genera error debido a que // variable final no puede ser modificada posicion_x = posicion_x + 1; } // Cierra void moverse } // Cierra interface animal public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App");
} }
MyApp f = new MyApp(); f.setSize(100,100); f.show();
Cabe anotar que verdaderamente la variable dentro de una clase interface es una variable tipo final por lo que no podr ser modificada ni siquiera por algn mtodo de las clases que implementen dicha interface. Se podra pensar que las variables de las clases tipo interface se comportan como constantes
11.14. CLASE QUE IMPLEMENTE CLASE TIPO INTERFAZ DEBE DEFINIR SUS MTODOS
Es importante notar que toda clase no interface que implemente otra clase tipo interface debe implementar todos sus mtodos. Por ejemplo el siguiente programa genera un error:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; public void moverse(); } // Cierra interface transporte // Esta clase no genera un error public class animal implements transporte{ public String tipo="mamifero"; // SE REQUIERE QUE AQUI SE HUBIESE // IMPLEMENTADO EL MTODO moverse() } // Cierra interface animal public MyApp() {
this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); }
Lo interesante del asunto es que con slo indicar que se est implementando el mtodo del programa anterior, ya el compilador no genera error, as en verdad no se est implementando dicho mtodo. Veamos pues sta correccin en el programa mejorado con respecto al mencionado:
public class MyApp extends Frame { // Esta clase no genera un error public interface transporte{ public int posicion_x=2; public int posicion_y=0; public void moverse(); } // Cierra interface transporte // Esta clase no genera un error public class animal implements transporte{ public String tipo="mamifero"; // El compilador no genera error // porque cree que se est implementando // el mtodo cuando en verdad no se // est implementando public void moverse(){ } // Cierra void moverse } // Cierra interface animal
public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); }
12. TODO A CERCA DE CLASES

Las clases son lo ms simple de Java. Todo en Java forma parte de una clase, es una clase o describe como funciona una clase. El conocimiento de las clases es fundamental para poder entender los programas Java. Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto. Todos los mtodos se definen dentro del bloque de la clase, Java no soporta funciones o variables globales. Esto puede despistar a los programadores de C++, que pueden definir mtodos fuera del bloque de la clase, pero esta posibilidad es ms un intento de no separarse mucho y ser compatible con C, que un buen diseo orientado a objetos. As pues, el esqueleto de cualquier aplicacin Java se basa en la definicin de una clase. Todos los datos bsicos, como los enteros, se deben declarar en las clases antes de hacer uso de ellos. En C la unidad fundamental son los ficheros con cdigo fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del bloque de la clase. Sin embargo, el compilador reemplazar esa sentencia con el contenido del fichero que se indique, que consistir, como es de suponer, en ms clases.
12.1. TIPOS DE CLASES

Hasta ahora slo se ha utilizado la palabra clave public para calificar el nombre de las clases que hemos visto, pero hay tres modificadores ms. Los tipos de clases que podemos definir son: abstract Una clase abstract tiene al menos un mtodo abstracto. Una clase abstracta no se instancia, sino que se utiliza como clase base para la herencia. final Una clase final se declara como la clase que termina una cadena de herencia. No se puede heredar de una clase final. Por ejemplo, la clase Math es una clase final. public Las clases public son accesibles desde otras clases, bien sea directamente o por herencia. Son accesibles dentro del mismo paquete en el que se han declarado. Para acceder desde otros paquetes, primero tienen que ser importadas. synchronizable Este modificador especifica que todos los mtodos definidos en la clase son sincronizados, es decir, que no se puede acceder al mismo tiempo a ellos desde distintos threads; el sistema se encarga de colocar los flags necesarios para evitarlo. Este mecanismo hace que desde threads diferentes se puedan modificar las mismas variables sin que haya problemas de que se sobreescriban.
12.2. VARIABLES Y METODOS DE INSTANCIA

Una clase en Java puede contener variables y mtodos. Las variables pueden ser tipos primitivos como int, char, etc. Los mtodos son funciones. Por ejemplo, en el siguiente trozo de cdigo podemos observarlo:
public MiClase { int i; public MiClase() { i = 10;
} public void Suma_a_i( int j ) { i = i + j; } }
La clase MiClase contiene una variable (i) y dos mtodos, MiClase que es el constructor de la clase y Suma_a_i( int j ).
12.3. AMBITO DE UNA VARIABLE

Los bloques de sentencias compuestas en Java se delimitan con dos llaves. Las variables de Java slo son vlidas desde el punto donde estn declaradas hasta el final de la sentencia compuesta que la engloba. Se pueden anidar estas sentencias compuestas, y cada una puede contener su propio conjunto de declaraciones de variables locales. Sin embargo, no se puede declarar una variable con el mismo nombre que una de mbito exterior. El siguiente ejemplo intenta declarar dos variables separadas con el mismo nombre. En C y C++ son distintas, porque estn declaradas dentro de mbitos diferentes. En Java, esto es ilegal.
Class Ambito { int i = 1; { int i = 2; } } // mbito exterior // crea un nuevo mbito // error de compilacin
12.4. METODOS Y CONSTRUCTORES

Los mtodos son funciones que pueden ser llamadas dentro de la clase o por otras clases. El constructor es un tipo especfico de mtodo que siempre tiene el mismo nombre que la clase. Cuando se declara una clase en Java, se pueden declarar uno o ms constructores opcionales que realizan la inicializacin cuando se instancia (se crea una ocurrencia) un objeto de dicha clase. Utilizando el cdigo de ejemplo anterior, cuando se crea una nueva instancia de MiClase, se crean (instancian) todos los mtodos y variables, y se llama al constructor de la clase:
MiClase mc; mc = new MiClase();
La palabra clave new se usa para crear una instancia de la clase. Antes de ser instanciada con new no consume memoria, simplemente es una declaracin de tipo. Despus de ser instanciado un nuevo objeto mc, el valor de i en el objeto mc ser igual a 10. Se puede referenciar la variable (de instancia) i con el nombre del objeto:
mc.i++; // incrementa la instancia de i de mc Al tener mc todas las variables y mtodos de MiClase, se puede mc.Suma_a_i( 10 );
usar la primera sintaxis para llamar al mtodo Suma_a_i() utilizando el nuevo nombre de clase mc: y ahora la variable mc.i vale 21.
12.5. FINALIZADORES
Java no utiliza destructores (al contrario que C++) ya que tiene una forma de recoger automticamente todos los objetos que se salen del alcance. No obstante proporciona un mtodo que, cuando se especifique en el cdigo de la clase, el reciclador de memoria (garbage collector) llamar:
// Cierra el canal cuando este objeto es reciclado protected void finalize() { close(); }
12.6. ALCANCE DE OBJETOS Y RECICLADO DE MEMORIA

Los objetos tienen un tiempo de vida y consumen recursos durante el mismo. Cuando un objeto no se va a utilizar ms, debera liberar el espacio que ocupaba en la memoria de forma que las aplicaciones no la agoten (especialmente las grandes). En Java, la recoleccin y liberacin de memoria es responsabilidad de un thread llamado automatic garbage collector (recolector automtico de basura). Este thread monitoriza el alcance de los objetos y marca los objetos que se han salido de alcance. Veamos un ejemplo:
String s; s = new String( "abc" ); s = "def"; // // // // no se ha asignado todavia memoria asignada se ha asignado nueva memoria (nuevo objeto)
Ms adelante veremos en detalle la clase String, pero una breve descripcin de lo que hace esto es; crear un objeto String y rellenarlo con los caracteres "abc" y crear otro (nuevo) String y colocarle los caracteres "def". En esencia se crean dos objetos:
Objeto String "abc" Objeto String "def"
Al final de la tercera sentencia, el primer objeto creado de nombre s que contiene "abc" se ha salido de alcance. No hay forma de acceder a l. Ahora se tiene un nuevo objeto llamado s y contiene "def". Es marcado y eliminado en la siguiente iteracin del thread reciclador de memoria.
13. EJERCICIO DEL PIRATA RESULADO DE LA PRIMERA ITERACION CON RUP
13.1. PLANTEAMIENTO DEL ENUNCIADO

Un pirata ebrio se tambalea al subir por una rampa del muelle a su barco. La rampa tiene cinco pasos de ancho y 15 de largo. Comenzamos a observar al pirata cuando est en el extremo de la rampa que se apoya sobre el muelle. Si da ms de dos pasos hacia la izquierda o la derecha, caer en el agua y se ahogar, pero si da ms de 15 pasos hacia delante estar a salvo a bordo de su barco.
13.2. ESTABLECIMIENTO DE FRASES IMPORTANTES.

Un pirata ebrio se tambalea Un pirata sube por una rampa La rampa tiene cinco pasos de ancho y 15 de largo. Observamos al pirata cuando est en el extremo de la barca La rampa se apoya sobre el muelle Si el pirata da mas de dos pasos hacia la izquierda se cae Si el pirata da mas de dos pasos hacia la derecha se cae. Cuando el pirata se cae, se ahoga Si el pirata da mas de 15 pasos hacia delante estar a salvo. Cuando est a salvo no se ahoga El pirata en el barco estar a salvo.
13.3. ESTABLECIMIENDO DE CLASES

pirata pos_x : int = null pos_y : int = null peso : int = 75 estado_vida : boolean = true moverse(int, int) : void dejarse_ahogar: void() mar ahogados : int = 0 ahogar(pirata) : void
barco mensaje : String = "" salvar_pirata: void()
MyApp grilla : GridLayout = new borde : BorderLayout = new paneles : panel[][] = new gp : Graphics = new actual_x : int = null actual_y : int = null superior : Panel = new arriba : Panel = new inferior : Panel = new ta : TextArea = new t1 : TextField = new IngSistemas : pirata = new Rampa : rampa = new Mar : mar = new salvado : boolean = false Barco : barco = new Muelle : muelle = new paint(Graphics) : void init() : void keyDown(Event, int) : boolean muelle peso_actual : int = 70 peso_cadena : String = "" informar_peso: void()
rampa pos_x : int = 0 pos_y : int = 0 mensaje : String = "El Muelle Habla" validar_salida(int, int) : void informar_caer_al_mar: void()
13.4. PROGRAMA EN JAVA
import java.awt.*; import java.awt.event.*; import java.applet.*; public class MyApp extends Applet { GridLayout grilla = new GridLayout(15,5,1,1); BorderLayout borde = new BorderLayout(4,4); Panel paneles[][] = new Panel[5][15]; Graphics gp[][] = new Graphics[5][15]; int actual_x, actual_y; Panel superior = new Panel(); Panel arriba = new Panel(); Panel inferior = new Panel(); TextArea ta = new TextArea(5,30); TextField t1 = new TextField("EL PIRATA PESA"); pirata IngSistemas = new pirata(); rampa Rampa = new rampa(); mar Mar = new mar(); boolean salvado = false; barco Barco = new barco(); muelle Muelle = new muelle(); public void paint(Graphics g) { for(int x = 0; x<5; x++){ for(int y = 0; y<15; y++){ gp[x][y] = paneles[x][y].getGraphics(); if(x == actual_x && y == actual_y){ paneles[x][y].setBackground(Color.red); } else{ paneles[x][y].setBackground(Color.white); } // Cierra else } // cierra for interno
} // cierra for externo // cierra paint()
public class mar{ public void ahogar(pirata hombre){ String cadena = ta.getText().trim(); cadena = cadena + "\n EL MAR HABLA: \n"; cadena = cadena + "ESTOY AHOGANDO AL MUERTO"; ta.setText(cadena); IngSistemas.dejarse_ahogar(); } } // Cierra class mar public void init(){ actual_x = 2; actual_y = 0; setLayout(borde); superior.setLayout(new BorderLayout(4,5)); superior.add("Center", arriba); add("Center", superior); add("South", inferior); inferior.add(ta); inferior.add(t1); arriba.setLayout(grilla); setBackground(Color.black); for(int x = 0; x<5; x++){ for(int y = 0; y<15; y++){ paneles[x][y] = new Panel(); } } for(int y = 0; y<15; y++){ for(int x = 0; x<5; x++){ arriba.add(paneles[x][y]); } } Muelle.soportar_peso(IngSistemas.peso); Muelle.informar_peso(); } // Cierra funcion init() public class barco{
String mensaje = ""; public void salvar_pirata(){ salvado = true; mensaje = ta.getText().trim(); mensaje = mensaje + "\n EL BARCO HABLA \n"; mensaje = mensaje + "SALVADO EL PIRATA"; ta.setText(mensaje); } } // Cierra class barco public class muelle{ int peso_actual = 70; String peso_cadena = ""; public void soportar_peso(int valor){ peso_actual = valor; } // Cierra void soportar_peso public void informar_peso(){ peso_cadena = t1.getText().trim(); peso_cadena = peso_cadena + " "; peso_cadena = peso_cadena + peso_actual; peso_cadena = peso_cadena + "KILOS "; t1.setText(peso_cadena); }// int informar_peso } // Cierra class muelle public class rampa{ int pos_x=0; int pos_y=0; String mensaje = "EL MUELLE HABLA; \n"; public void validar_salida(int x, int y){ pos_x = x; pos_y = y; if(pos_y<0){ mensaje = mensaje + "Fuera del rango y"; ta.setText(mensaje); tirar_al_mar(); } if(pos_x<0){
mensaje = mensaje + "Fuera del rango x"; ta.setText(mensaje); tirar_al_mar(); } if(pos_x>=5){ mensaje = mensaje + "Fuera del rango x"; ta.setText(mensaje); tirar_al_mar(); } if(pos_y>=15){ mensaje = mensaje + "NO LO DEJE CAER"; ta.setText(mensaje); Barco.salvar_pirata(); } } // Cierra void validar_salida() public void tirar_al_mar(){ Mar.ahogar(IngSistemas); } // Cierra void tirar_al_mar() } // Cierra class rampa public class pirata{ int pos_x; int pos_y; int peso = 75; // Kilos boolean estado_vida = true; public void moverse(int i, int j){ if(estado_vida){ pos_x = i; pos_y = j; Rampa.validar_salida(pos_x, pos_y); } // Cierra if } // Cierra moverse public void dejarse_ahogar(){ estado_vida = false; } //Cierra void dejarse_ahogar } // Cierra clase pirata
public boolean keyDown(Event evt, int key){ if(IngSistemas.estado_vida && salvado==false){ switch(key){ case Event.RIGHT: actual_x++; IngSistemas.moverse(actual_x, actual_y); repaint(); break; case Event.LEFT: actual_x--; IngSistemas.moverse(actual_x, actual_y); repaint(); break; case Event.UP: actual_y--; IngSistemas.moverse(actual_x, actual_y); repaint(); break; case Event.DOWN: actual_y++; IngSistemas.moverse(actual_x, actual_y); repaint(); break; } return true; } // Cierra if externo return false; } // Cierra boolean } // Cierra clase MyApp
13.5. EJECUCIN DEL PROGRAMA:

El programa anterior muestra una grilla en donde se encuentra una celda que tiene un color rojo a diferencia de las dems celdas. Esto para el caso del programa que estamos explicando indica que el pirata se encuentra en dicha posicin.
Ahora bien, el usuario, puede desplazarse mediante las teclas de direccin del teclado y de esta manera podr mover el pirata. (que en este caso es la posicin roja). Si el usuario no lo deja desbordarse por alguna posicin de la derecha o de la izquierda y llega a la posicin de debajo de la figura, se obtiene un resultado similar al siguiente:
Pero si el usuario lo deja desbordarse por la derecha o por la izquierda, aparecer una pantalla similar a la siguiente:
Con lo cual se indica que efectivamente se ha caido el pirata al mar y por supuesto se ha ahogado.
14. EJERCICIO DEL AVION
14.1. DIAGRAMA DE CLASE
avion h : Graphics = null x : int = 150 y : int = 400 cuerpo : rectangulo = new cola : rectangulo = new ala_superior : triangulo = new ala_inferior : triangulo = new punta : triangulo = new matriz : int[][] = new int[17][4] colita : int[][] = null cuerpito : int[][] = null puntica : int[][] = null alita_arriba : int[][] = null alita_abajo : int[][] = new trompita : int[][] = new alejarse() : void ascender() devolver_grafica() : int[][] moverse() avion()
rectangulo h : Graphics = null posx : int = null posy : int = null ancho : int = null alto : int = null rectangulillo : int[][] = new rectangulo() devolver_grafica: int[][]() posicion_derecha: int() posicion_superior: int() posicion_inferior: int() posicionar(rectangulo) : void actualizar_rectangulo(int int int int) : void alargar: void() adelgazar: void() triangulo posx : int = null posy : int = null posx1 : int = null posy1 : int = null posx2 : int = null posy2 : int = null pos : int[][] = new alto : int = null devolver_grafica: int[][]() ajustarse(String) : void ajustarse(String, rectangulo) : void triangulo()
canvitas gra : Graphics = null pintar : int = 0 puntos : int = null apariciones : int = 100 referencia_avion : avion = null pintar(avion) : void paint(Graphics) : void 1..1
1..1
MyApp tablero : canvitas = new avioncito : avion = new MyApp() main()
14.2. EXPLICACIN DE LA IMPLEMENTACIN

La implementacin del ejercicio anterior se hizo basndose en el concepto que la mejor forma para trabajar orientado a objetos es crear una clase en un archivo a medida que el programa que se va ha realizar crezca de complejidad. En ltimas sta tcnica ayuda a un buen mantenimiento de los aplicativos y aunque a nivel de mquina no siempre resulta ser la mejor opcin, por lo menos si asegura ser la mejor opcin cuando se requieran hacer modificaciones al respecto. A continuacin se muestran pues los contenidos de cada uno de los archivos que llevan a solucionar el problema del avin. Veamos pues:
avion.java
import java.awt.*; import java.awt.event.*; import java.applet.*; public class avion{ Graphics h; int x = 150; int y = 400;
rectangulo cuerpo = new rectangulo(); rectangulo cola = new rectangulo(); triangulo ala_superior = new triangulo(); triangulo ala_inferior = new triangulo(); triangulo punta = new triangulo(); int matriz[][] = new int[17][4]; int colita[][]; int cuerpito[][]; int puntica[][]; int alita_arriba[][]; int alita_abajo[][] = new int[3][4]; int trompta[][] = new int[3][4]; public avion(){ // Por medio de punta se establece // el tamao del avion punta.alto = 40; }// Cierra public avion public void alejarse(){ if(punta.alto>10){ punta.alto = punta.alto - 1; }// Cierra ir } // Cierra void alejarse public void ascender(){ if(y>20){ y = y - 5; }// Cierra ir } // Cierra void alejarse public int[][] devolver_grafica(){ // punta.alto = 20; punta.posx = x; punta.posy = y; punta.ajustarse("punta"); cuerpo.alto = punta.alto;
cuerpo.ancho = cuerpo.alto*6; cuerpo.posx = punta.posx1-cuerpo.ancho; cuerpo.posy = punta.posy - (int)punta.alto/2; cola.posicionar(cuerpo); ala_superior.ajustarse("ala_superior", cuerpo); ala_inferior.ajustarse("ala_inferior", cuerpo); colita = cola.devolver_grafica(); puntica = punta.devolver_grafica(); cuerpito = cuerpo.devolver_grafica(); alita_arriba = ala_superior.devolver_grafica(); alita_abajo = ala_inferior.devolver_grafica(); for(int i = 0; i<4; i++){ for(int j = 0; j<4; j++){ matriz[i][j] = colita[i][j]; } // Cierra for interno for(int k = 0; k<4; k++){ matriz[i+4][k] = cuerpito[i][k]; } // Cierra for interno for(int m = 0; m<3; m++){ matriz[m+8][i] = puntica[m][i]; } // Cierra for interno for(int n = 0; n<3; n++){ matriz[n+11][i] = alita_arriba[n][i]; } // Cierra for interno for(int p = 0; p<3; p++){ matriz[p+14][i] = alita_abajo[p][i]; } // Cierra for interno } // Cierra for externo return matriz; } // Cierra devolver_grafica public void moverse(){ x = x+8; }// Cierra void moverse } // Cierra class avion
canvitas.java import java.awt.*; import java.awt.event.*; import java.applet.*; public class canvitas extends Canvas{ Graphics gra; int pintar = 0; int puntos[][]; int apariciones = 100; avion referencia_avion; public void pintar(avion obj_volador){ puntos = obj_volador.devolver_grafica(); referencia_avion = obj_volador; repaint(); } // Cierra pintar public void paint(Graphics g){ this.gra = g; g.setColor(Color.blue); while(apariciones>0){ referencia_avion.moverse(); referencia_avion.alejarse(); referencia_avion.ascender(); puntos = referencia_avion.devolver_grafica(); g.setColor(Color.blue); for(int i = 0; i<17; i++){ g.drawLine(puntos[i][0], puntos[i][1], puntos[i][2], puntos[i][3]); } try{ Thread.sleep(40); } catch(InterruptedException e){ } // Cierra catch g.setColor(Color.yellow); for(int i = 0; i<17; i++){ g.drawLine(puntos[i][0], puntos[i][1], puntos[i][2], puntos[i][3]); } setBackground(Color.yellow); g.drawString("ESTO ES EL CANVAS", 200,300);
apariciones--; } // Cierra while } // Cierra public void paint } // Cierra class canvitas
MyApp.java import java.awt.*; import java.awt.event.*; public class MyApp extends Frame { canvitas tablero = new canvitas(); avion avioncito = new avion(); int apariciones = 500; public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); add(tablero); tablero.pintar(avioncito); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(960,600); f.show(); } }
rectangulo.java
import java.awt.*; import java.applet.*; public class rectangulo{ Graphics h; int posx, posy, ancho, alto; int rectangulillo[][] = new int[4][4]; public rectangulo(){ } // Cierra public rectangulo public int[][] devolver_grafica(){ rectangulillo[0][0] = posx; rectangulillo[0][1] = posy; rectangulillo[0][2] = posx+ancho; rectangulillo[0][3] = posy; rectangulillo[1][0] rectangulillo[1][1] rectangulillo[1][2] rectangulillo[1][3] rectangulillo[2][0] rectangulillo[2][1] rectangulillo[2][2] rectangulillo[2][3] = = = = = = = = posx; posy; posx; posy+alto; posx+ancho; posy; posx+ancho; posy+alto;
rectangulillo[3][0] = posx; rectangulillo[3][1] = posy+alto; rectangulillo[3][2] = posx+ancho; rectangulillo[3][3] = posy+alto; return rectangulillo; } // Cierra int[][] devolver_grafica public int posicion_derecha(){ return posx+ ancho; } // Cierra int posicion_derecha public int posicion_superior(){ return posy;
} // Cierra int posicion_superior public int posicion_inferior(){ return posy+alto; } // Cierra int posicion_inferior public void posicionar(rectangulo rect){ ancho = (int)rect.ancho/5; alto = rect.alto*3; posx = rect.posx -ancho; posy = rect.posy - (rect.alto); } // Cierra mover_derecha public void actualizar_rectangulo(int x, int y, int ancho, int alto){ posx = x; posy = y; this.ancho = ancho; this.alto = alto; } // Cierra public rectangulo public void alargar(int valor){ ancho = ancho + valor; } // Cierra alargar public void adelgazar(int valor){ alto = alto - valor; } // Cierra adelgargar } // Cierra class rectangulo
triangulo.java
import java.applet.*; public class triangulo{ int posx; int posy; int posx1; int posy1; int posx2; int posy2; int pos[][] = new int[3][4]; int alto; public int[][] devolver_grafica(){ pos[0][0] = posx; pos[0][1] = posy; pos[0][2] = posx1; pos[0][3] = posy1; pos[1][0] pos[1][1] pos[1][2] pos[1][3] pos[2][0] pos[2][1] pos[2][2] pos[2][3] = = = = = = = = posx; posy; posx2; posy2; posx1; posy1; posx2; posy2;
return pos; } // Cierra int[][] devolver_grafica
public void ajustarse(String tipo){ if(tipo.equals("punta")){ posx1 = posx - (int)alto; posy1 = posy - (int)alto/2; posx2 = posx - (int)alto; posy2 = posy + (int)alto/2;
System.out.println("posx = "+ posx ); System.out.println("posy = "+ posy ); System.out.println("posx1 = "+ posx1 ); System.out.println("posy1 = "+ posy1 ); System.out.println("posx2 = "+ posx2 ); System.out.println("posy2 = "+ posy2 ); } }// Cierra if tipo == "punta" public void ajustarse(String tipo, rectangulo body){ if(tipo.equals("ala_superior")){ posy = body.posy - body.alto*2; posx = body.posx + (int )body.ancho/3; posx1 = body.posx + (int)body.ancho/3 + (int)body.ancho/6; posy1 = body.posy; posx2 = body.posx + (int)body.ancho/3 + (int)body.ancho/3; posy2 = body.posy; }// Cierra if tipo == "ala_superior" if(tipo.equals("ala_inferior")){ posy = body.posy + body.alto + body.alto*2; posx = body.posx + (int )body.ancho/3; posx1 = body.posx + (int)body.ancho/3 + (int)body.ancho/6; posy1 = body.posy + body.alto; posx2 = body.posx + (int)body.ancho/3 + (int)body.ancho/3; posy2 = body.posy + body.alto; System.out.println("ESTOY EN EL FI"); System.out.println("posx = "+ posx); System.out.println("posy = "+ posy); System.out.println("posx1 = "+ posx1); System.out.println("posy1 = "+ posy1); System.out.println("posx2 = "+ posx2); System.out.println("posy2 = "+ posy2); }// Cierra if tipo == "ala_superior" } // Cierra void ajustarse public triangulo(){
// Cierra triangulo
} // Cierra class triangulo
14.3. EJECUCIN DEL PROGRAMA
Inicialmente el programa aparece el avin de la siguiente manera:
Y a medida que pasa el tiempo se va elevando el avin, tal como se muestra en la siguiente
grfica: Finalmente el avin llega a un punto en el que alcanza la altura mxima y contina volando.
15. LA CLONACION DE OBJETOS

La clonacin es uno de los temas que mas se olvida a la hora de trabajar con aplicaciones JAVA, pero es uno de los temas que estudindolos a profundidad dan la fundamentacin para hacer aplicaciones de gran versatilidad, distribuidas y sobretodo aplicaciones que conserven estados de objetos, que manejen mayor seguridad al tener objetos que conservan el estado en el que se encontraba otro objeto cuando se le clono. En pocas palabras podemos pensar que la clonacin trae muchas ventajas que por lo general no son tan claras, ni tan evidentes, pero que abren la puerta hacia mejores y mas robustas aplicaciones JAVA.
15.1. COPIA DE OBJETOS LIMITADA

Uno de los problemas ms interesantes de la programacin orientada a objetos es el tema de la copia de objetos. Supongamos que creamos un objeto llamado origen (El programa completo se muestra al final de esta seccin) que es de la clase Original, podramos pensar que este objeto en su ciclo de vida sufre en algn momento algunas modificaciones en sus atributos y en fin en sus estados, cosa que es inherente a todo objeto. La cuestin que nos interesa es que despus de saber que el objeto origen ya ha cambiado de estado, se desea hacer una copia de dicho objeto, pero que la copia sea completa, es decir que el nuevo objeto tenga los valores que tenia el objeto copiado. Esto aparentemente es algo sencillo que eventualmente se podra solucionar de cualquier forma, pero es importante que el amigo lector / estudiante comprenda que la solucin planteada en esta seccin es bastante limitada y no ser muy til cuando los objetos que se deseen duplicar tengan una complejidad mayor. Por el momento decimos que tenemos una clase Original que tiene el siguiente cdigo fuente:
public class Original{ int parametro1 = 1; int parametro2 = 2; int parametro3 = 3; int parametro4 = 4; boolean estado = true; public void printPar1(){ System.out.println("Parametro 1 = "+parametro1); } // Cierra setParametro1 public void printPar2(){ System.out.println("Parametro 2 = "+parametro2); } // Cierra setParametro1 public void printPar3(){ System.out.println("Parametro 3 = "+parametro3);
} // Cierra setParametro1 public void printPar4(){ System.out.println("Parametro 4 = "+parametro4); } // Cierra setParametro1 public void printEstado(){ if(estado){ System.out.println("Estado = true"); } else{ System.out.println("Estado = false"); } } public void cambiarEstado(){ if(estado){ estado = false; } else{ estado = true; } } public void printParametros(String objetin){ System.out.println("Parametros de "+objetin); printPar1(); printPar2(); printPar3(); printPar4(); printEstado(); } // Cierra void printParametros() public void modificarParametros(){ parametro1 = 10; parametro2 = 20; parametro3 = 30; parametro4 = 40; cambiarEstado(); } // Cierra void modificarParametros() public Object copiar(){ // Original objOriginal = new Original(); Original objOriginal = this; System.out.println("Copiando objeto"); Original retornar = new Original(); retornar.parametro1 = objOriginal.parametro1; retornar.parametro2 = objOriginal.parametro2; retornar.parametro3 = objOriginal.parametro3; retornar.parametro4 = objOriginal.parametro4; retornar.estado = objOriginal.estado; return retornar; } // Cierra void copiar() } // Cierra class Original
En la cual encontramos que se tienen cinco atributos a saber: Parametro1, Parametro2, Parametro3, Parametro4 y estado, los cuales tienen inicialmente los siguientes valores: parmetro parametro1 parametro2 parametro3 parametro4 estado Valor 1 2 3 4 true
Decimos que queremos modificar los atributos de dicho objeto y esto se hace ejecutando del cdigo anterior las siguientes instrucciones: Es decir ejecutando las instrucciones
parametro1 parametro2 parametro3 parametro4 = = = = 10; 20; 30; 40;
junto con las instrucciones:

public void cambiarEstado(){ if(estado){ estado = false; } else{ estado = true; } }
Obviamente estas instrucciones cambian el estado del objeto ObjOriginal definido en el mtodo ejecutarCopia():
public void ejecutarCopia(){ Original origen = new Original(); origen.printParametros("Original "); origen.modificarParametros(); origen.printParametros("Original "); Original destino; destino = (Original)origen.copiar(); destino.printParametros("Destino "); } // Cierra void ejecutarCopia()
Y este es precisamente el mtodo que tiene toda la lgica del programa que queremos explicar. El programa crea el objeto llamado origen:
Original origen = new Original();
Despus de lo cual imprime los datos de dicho objeto, con lo cual se produce por la vista consola una salida que muestra los datos contenidos en la siguiente tabla: parmetro parametro1 parametro2 parametro3 parametro4 estado Valor 1 2 3 4 true
Despus modifica los parmetros del mencionado objeto, con lo cual modifica el estado del objeto cuando ejecuta la instruccin:
origen.modificarParametros();
La cual modifica los parmetros expuestos en la anterior tabla y luego se vuelven a imprimir los parmetros del mismo objeto para tener la certeza que realmente se han cambiado los parmetros del objeto tal como venan desde la creacin del objeto. Esto se logra con las instrucciones:
public void modificarParametros(){ parametro1 = 10; parametro2 = 20; parametro3 = 30; parametro4 = 40; cambiarEstado(); } // Cierra void modificarParametros()
Y para tener la certeza que efectivamente se han cambiado los parmetros del objeto, se imprimen nuevamente los parmetros del objeto origen:
Con lo cual se producen unos resultados por consola similar a los mostrados en la siguiente tabla: parmetro Valor
parametro1 parametro2 parametro3 parametro4 estado
10 20 30 40 false
Y finalmente se saca una copia al objeto origen, invocando el mtodo copiar() del mencionado objeto.
El procedimiento de copia crea un objeto nuevo llamado destino con los atributos que aparecen en la declaracin de la clase del objeto, es decir con los datos: parmetro parametro1 parametro2 parametro3 parametro4 estado Valor 1 2 3 4 true
Pero para simular que la copia es del objeto llamado original es cierta, se copian uno a uno los valores de los atributos del objeto original al objeto destino. Lo cual se encuentra en el mtodo copiar:
public Object copiar(){ // Original objOriginal = new Original(); Original objOriginal = this; System.out.println("Copiando objeto"); Original retornar = new Original(); retornar.parametro1 = objOriginal.parametro1; retornar.parametro2 = objOriginal.parametro2; retornar.parametro3 = objOriginal.parametro3; retornar.parametro4 = objOriginal.parametro4; retornar.estado = objOriginal.estado; return retornar; } // Cierra void copiar()
Claro, la pregunta que viene es: Qu pasa si el numero de atributos es mas grande?. La respuesta podra ser aumentar el numero de instrucciones en nuestro programa que ejecute estas instrucciones, pero la verdad hay otras soluciones mejores como la de crear un vector
con los valores iniciales, para que al modificarlos, ser simple cosa de hacer un ciclo for. Obviamente esta solucin es bastante limitada debido a que si el tipo de atributos del objeto son variados, la cuestin es un poco mas compleja, pero si el objeto a su vez esta conformado por objetos internos que tienen un estado particular, la cuestin de sacarle copia a un objeto ser cosa bastante complicada. Y para finalizar la explicacin es bueno tener en cuenta que el programa completo al que estamos haciendo referencia en esta seccin es el siguiente:
/****************************************************************** Nombre : CopiaObjetos.java Descripcion : El siguiente programa muestra como se : pueden sacar copias de objetos en forma : manual y artesanal Tipo: : No Maneja apuntadores, maneja referencias : Es de tipo AUTONOMO : El programa no usa la interfaz CLONABLE : para sacar copias de objetos Autor : Luis Felipe Wanumen luchofelipe2000@yahoo.com Revision : No hay revisiones por el momento. Agradecimientos : No hay D.Historico : 03/08/2007 ******************************************************************/ import java.awt.*; import java.awt.event.*; public class CopiaObjetos extends Frame { public class Original{ int parametro1 = 1; int parametro2 = 2; int parametro3 = 3; int parametro4 = 4; boolean estado = true; public void printPar1(){ System.out.println("Parametro 1 = "+parametro1); } // Cierra setParametro1 public void printPar2(){ System.out.println("Parametro 2 = "+parametro2); } // Cierra setParametro1 public void printPar3(){ System.out.println("Parametro 3 = "+parametro3); } // Cierra setParametro1 public void printPar4(){ System.out.println("Parametro 4 = "+parametro4); } // Cierra setParametro1 public void printEstado(){ if(estado){
} public void cambiarEstado(){ if(estado){ estado = false; } else{ estado = true; } }
System.out.println("Estado = true"); } else{ System.out.println("Estado = false"); }
public void printParametros(String objetin){ System.out.println("Parametros de "+objetin); printPar1(); printPar2(); printPar3(); printPar4(); printEstado(); } // Cierra void printParametros() public void modificarParametros(){ parametro1 = 10; parametro2 = 20; parametro3 = 30; parametro4 = 40; cambiarEstado(); } // Cierra void modificarParametros() public Object copiar(){ // Original objOriginal = new Original(); Original objOriginal = this; System.out.println("Copiando objeto"); Original retornar = new Original(); retornar.parametro1 = objOriginal.parametro1; retornar.parametro2 = objOriginal.parametro2; retornar.parametro3 = objOriginal.parametro3; retornar.parametro4 = objOriginal.parametro4; retornar.estado = objOriginal.estado; return retornar; } // Cierra void copiar() } // Cierra class Original public void ejecutarCopia(){ Original origen = new Original(); origen.printParametros("Original "); origen.modificarParametros(); origen.printParametros("Original "); Original destino; destino = (Original)origen.copiar(); destino.printParametros("Destino "); } // Cierra void ejecutarCopia() public CopiaObjetos()
this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } // Cierra CopiaObjetos() public static void main(String args[]) { System.out.println("Starting App"); CopiaObjetos f = new CopiaObjetos(); f.setSize(100,100); f.setVisible(true); f.ejecutarCopia(); } // Cierra void main
Y para lograr la mayor comprensin de este tema, a continuacin se muestran los resultados obtenidos de la ejecucin del programa anterior: Starting App Parametros de Original Parametro 1 = 1 Parametro 2 = 2 Parametro 3 = 3 Parametro 4 = 4 Estado = true Parametros de Original Parametro 1 = 10 Parametro 2 = 20 Parametro 3 = 30 Parametro 4 = 40 Estado = false Copiando objeto Parametros de Destino Parametro 1 = 10 Parametro 2 = 20 Parametro 3 = 30 Parametro 4 = 40 Estado = false En el cual queda claro que los datos del objeto original eran inicialmente los siguientes: OBJETO ORIGINAL PARMETRO VALOR parametro1 1 parametro2 2
parametro3 parametro4 Estado
3 4 true
Se modificaron artesanalmente los datos del objeto en cuestin y se obtuvieron los siguientes datos: OBJETO ORIGINAL PARMETRO VALOR parametro1 10 parametro2 20 parametro3 30 parametro4 40 Estado false Y despus de ello se saco una copia del objeto ORIGINAL en el objeto DESTINO, con lo cual al imprimir los datos del nuevo objeto creado se obtuvieron los siguientes resultados: OBJETO DESTINO PARMETRO VALOR parametro1 10 parametro2 20 parametro3 30 parametro4 40 Estado false
En el caso del presente ejercicio, era factible sacarle una copia al objeto debido a que los elementos que contenan se les poda sacar copia, pero el problema es cuando los atributos que tiene un objeto no son tan sencillos como del ejercicio en cuestin.
15.2. COPIAR OBJETOS CON INTERFAZ CLONEABLE

La seccin anterior mostraba un ejercicio en el cual se poda sacar una copia a un objeto sin necesidad de hacer cosas extraas, pero la verdad es muy posible que en aplicaciones reales los objetos tengan una complejidad mas grande, que hagan que sus atributos sean tan complejos que sacarle una copia a dicho objeto sea cosa complicada. Para solucionar esta problemtica, JAVA incorpora en sus APIS la posibilidad de usar la interfaz Cloneable. El siguiente ejercicio muestra como hacer la copia del ejemplo de la seccin anterior, pero esta vez usando la interfaz Cloneable, veamos:
/****************************************************************** Nombre : Cloncito.java Descripcion : El siguiente programa muestra como se : pueden sacar copias de objetos al estilo : JAVA, es decir usando las APIS de JAVA : para este proposito. Tipo: : No Maneja apuntadores, maneja referencias : Es de tipo AUTONOMO : El programa usa la interfaz CLONABLE : para sacar copias de objetos Autor : Luis Felipe Wanumen luchofelipe2000@yahoo.com Revision : No hay revisiones por el momento. Agradecimientos : No hay D.Historico : 03/08/2007 ******************************************************************/ import java.awt.*; import java.awt.event.*; public class Cloncito extends Frame { public class Original implements Cloneable{ int parametro1 = 1; int parametro2 = 2; int parametro3 = 3; int parametro4 = 4; boolean estado = true; public void printPar1(){ System.out.println("Parametro 1 = "+parametro1); } // Cierra setParametro1 public void printPar2(){ System.out.println("Parametro 2 = "+parametro2); } // Cierra setParametro1 public void printPar3(){ System.out.println("Parametro 3 = "+parametro3); } // Cierra setParametro1 public void printPar4(){
System.out.println("Parametro 4 = "+parametro4); } // Cierra setParametro1 public void printEstado(){ if(estado){ System.out.println("Estado = true"); } else{ System.out.println("Estado = false"); } } public void cambiarEstado(){ if(estado){ estado = false; } else{ estado = true; } } public void printParametros(String objetin){ System.out.println("Parametros de "+objetin); printPar1(); printPar2(); printPar3(); printPar4(); printEstado(); } // Cierra void printParametros() public void modificarParametros(){ parametro1 = 10; parametro2 = 20; parametro3 = 30; parametro4 = 40; cambiarEstado(); } // Cierra void modificarParametros() public Object copiar(){ // Original objOriginal = new Original(); Original objOriginal = this; System.out.println("Copiando objeto"); Object retornar; try{ Object objeto = (Original)objOriginal.clone(); retornar = objeto; return retornar; } catch(Exception e){ return null; } } // Cierra void copiar() public Object Clone(){ try{ return super.clone(); }
catch(CloneNotSupportedException e){ return null; } } // Cierra public Object Clone } // Cierra class Original public void ejecutarClonacion(){ Original origen = new Original(); origen.printParametros("Original "); origen.modificarParametros(); origen.printParametros("Original "); Original destino; destino = (Original)origen.copiar(); destino.printParametros("Destino "); } public Cloncito() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); } // Cierra Cloncito() public static void main(String args[]) { System.out.println("Starting App"); Cloncito f = new Cloncito(); f.setSize(100,100); f.setVisible(true); f.ejecutarClonacion(); } // Cierra void main }
Observe amigo lector / estudiante que en el ejemplo anterior no hay necesidad de sacarle copia a cada uno de los atributos que componen el objeto original, debido a que la interfaz Cloneable se encarga de hacer esta labor. Es interesante observar que el tipo de elementos que componen al objeto que se le va a sacar un clon, no hay que programarlo y esto se vuelve una labor transparente al programador. A manera de aclarar la ejecucin del programa anterior, a continuacin se muestran los resultados generados por el mencionado: Starting App Parametros de Original Parametro 1 = 1 Parametro 2 = 2 Parametro 3 = 3 Parametro 4 = 4 Estado = true Parametros de Original
Parametro 1 = 10 Parametro 2 = 20 Parametro 3 = 30 Parametro 4 = 40 Estado = false Copiando objeto Parametros de Destino Parametro 1 = 10 Parametro 2 = 20 Parametro 3 = 30 Parametro 4 = 40 Estado = false Exit code: 0
15.3. LA INTERFAZ CLONEABLE ABARCA SUBOBJETOS

Cuando se clona un objeto, tambien se estan clonando los subobjetos que se encuentran dentro de dicho objeto. Para aclarar este concepto, a continuacin se aade al ejemplo de la seccion anterior un subobjeto para verificar si la clonacion cobija a los subobjetos del objeto clonado. Veamos pues el programa modificado:
/****************************************************************** Nombre : Cloncito1.java Descripcion : El siguiente programa muestra como se : pueden sacar copias de objetos al estilo : JAVA, es decir usando las APIS de JAVA : para este proposito. Tipo: : No Maneja apuntadores, maneja referencias : Es de tipo AUTONOMO : El programa usa la interfaz CLONABLE : para sacar copias de objetos Autor : Luis Felipe Wanumen luchofelipe2000@yahoo.com Revision : No hay revisiones por el momento. Agradecimientos : No hay D.Historico : 03/08/2007 ******************************************************************/ import java.awt.*; import java.awt.event.*; public class Cloncito1 extends Frame { public class Original implements Cloneable{ int parametro1 = 1; int parametro2 = 2; int parametro3 = 3; int parametro4 = 4;
public class Interna{ int p1 = 11; int p2 = 22; int p3 = 33; } // Cierra class Interna Interna objInterno = new Interna(); boolean estado = true; public void printPar1(){ System.out.println("Parametro 1 = "+parametro1); } // Cierra setParametro1 public void printPar2(){ System.out.println("Parametro 2 = "+parametro2); } // Cierra setParametro1 public void printPar3(){ System.out.println("Parametro 3 = "+parametro3); } // Cierra setParametro1 public void printPar4(){ System.out.println("Parametro 4 = "+parametro4); } // Cierra setParametro1 public void printEstado(){ if(estado){ System.out.println("Estado = true"); } else{ System.out.println("Estado = false"); } } // Cierra public void printEstado() public void cambiarEstado(){ objInterno.p1 = 111; objInterno.p2 = 222; objInterno.p3 = 333; if(estado){ estado = false; } else{ estado = true; } } // Cierra cambiarEstado() public void printParametros(String objetin){ System.out.println("Parametros de "+objetin); printPar1(); printPar2(); printPar3(); printPar4(); printEstado(); System.out.println("ATRIBUTOS DEL OBJETO INTERNO");
System.out.println("p1 = "+objInterno.p1); System.out.println("p2 = "+objInterno.p2); System.out.println("p3 = "+objInterno.p3); } // Cierra void printParametros() public void modificarParametros(){ parametro1 = 10; parametro2 = 20; parametro3 = 30; parametro4 = 40; cambiarEstado(); } // Cierra void modificarParametros() public Object copiar(){ // Original objOriginal = new Original(); Original objOriginal = this; System.out.println("Copiando objeto"); Object retornar; try{ Object objeto = (Original)objOriginal.clone(); retornar = objeto; return retornar; } catch(Exception e){ return null; } } // Cierra void copiar() public Object Clone(){ try{ return super.clone(); } catch(CloneNotSupportedException e){ return null; } } // Cierra public Object Clone } // Cierra class Original public void ejecutarClonacion(){ Original origen = new Original(); origen.printParametros("Original "); origen.modificarParametros(); origen.printParametros("Original "); Original destino; destino = (Original)origen.copiar(); destino.printParametros("Destino "); } public Cloncito1() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } });
} // Cierra Cloncito() public static void main(String args[]) { System.out.println("Starting App"); Cloncito1 f = new Cloncito1(); f.setSize(100,100); f.setVisible(true); f.ejecutarClonacion(); } // Cierra void main }
El cual produce el siguiente resultado: Starting App Parametros de Original Parametro 1 = 1 Parametro 2 = 2 Parametro 3 = 3 Parametro 4 = 4 Estado = true ATRIBUTOS DEL OBJETO INTERNO p1 = 11 p2 = 22 p3 = 33 Parametros de Original Parametro 1 = 10 Parametro 2 = 20 Parametro 3 = 30 Parametro 4 = 40 Estado = false ATRIBUTOS DEL OBJETO INTERNO p1 = 111 p2 = 222 p3 = 333 Copiando objeto Parametros de Destino Parametro 1 = 10 Parametro 2 = 20 Parametro 3 = 30 Parametro 4 = 40 Estado = false ATRIBUTOS DEL OBJETO INTERNO p1 = 111 p2 = 222 p3 = 333 Exit code: 0
Con lo cual vemos que los valores del subojeto eran inicialmente: p1 = 11 p2 = 22 p3 = 33 y fueron modificados intencionalmente por los siguientes en su objeto ORIGEN: p1 = 111 p2 = 222 p3 = 333 pero lo interesante del asunto es que el objeto DESTINO, cuando se imprimen los valores de los subobjetos, tambin tiene en cuenta el subobjeto. Con todo esto se puede concluir que la clonacin, tiene grandes ventajas cuando de sacarle copia a objetos complejos se trate. De tarea se deja al amigo / lector estudiante para compruebe por su propia cuenta que la clonacin cobija a cualquier atributo de objeto incluido en la clase a ser clonable.
16. CLASES TIPO OBSERVER Y OBSERVABLE

En el lenguaje JAVA, existen unas APIS que permiten crear nuestras propias clases que puedan ser observadas por otras clases, a este tipo de clases se les conoce con el nombre de clases OBSERVABLE, tambin existen clases que observan a las clases anteriormente mencionadas y a este tipo de clases se les denomina clases tipo OBSERVER.
16.1. ESTRUCTURA DE LAS CLASES OBSERVABLES

Una de las caractersticas de las clases observables es que extienden de la clase Observable que se encuentra en el paquete java.util. Por lo general esta clase contiene propiedades del tipo set y get seguidas de un nombre con el fin de establecer y devolver los valores de dicha clase. Un ejemplo de una clase tipo Observable es la siguiente:
import java.util.Observable; public class Persona extends Observable { private int edad; public Persona(){ edad = 0; } public int getEdad(){ return edad; } public void crecer(){ System.out.println("La edad era: "+edad); setEdad(getEdad()+1); System.out.println("La edad ahora es: "+edad); } // Propiedad para asignar el valor de la edad // Las clases que estan pendientes de cambios en edad // son notificadas de dicho cambio. public void setEdad(int edad) { this.edad = edad; setChanged(); notifyObservers(); } } // Cierra class Persona
16.2. ESTRUCTURA DE LAS CLASES OBSERVER

Las clases tipo OBSERVER implementan de la clase OBSERVER que se encuentra en el paquete java.util, tienen principalmente un mtodo que las caracteriza que es el mtodo update(), el cual se ejecuta cuando la clase OBSERVABLE modifica su valor o sufre un cambio de estado. Un ejemplo de una clase OBSERVER es la siguiente:
import java.util.Observer; import java.util.Observable; public class ObservadorPersona implements Observer{ private Persona personaObservable=null; private Observacion refVentana; public ObservadorPersona(Persona personaObservable){ this.personaObservable = personaObservable; } public void update(Observable observable, Object objeto){ if(observable == personaObservable){ this.refVentana.ta.setText("Edad vista por el observador: "+personaObservable.getEdad()); } } public void setVentana(Observacion refVentana){ this.refVentana = refVentana; } } // Cierra class ObservadorPersona
16.3. CREACION DE OBJETOS DE TIPO OBSERVER Y OBSERVABLE

Supongamos que basados en las clases de las anteriores dos secciones creamos un objeto llamado luisfelipe de tipo Persona y otro objeto llamado chismoso de tipo ObservadorPersona, tendramos que la creacin de estos objetos se podra hacer tal como se muestra a continuacin:
public Persona luisfelipe = null; public Persona luisfelipe = null; luisfelipe = new Persona(); chismoso = new ObservadorPersona(luisfelipe);
16.4. VINCULACION DEL OBJETO OBSERVABLE AL OBJETO OBSERVER

En la anterior seccin se han creado los objetos de tipo OBSERVER y de tipo OBSERVABLE, pero en ningn momento se ha especificado que el objeto llamado chismoso es capaz de observar concretamente al objeto llamado luisfelipe esto se logra mediante la instruccin:
luisfelipe.addObserver( chismoso );
16.5. UN EJEMPLO COMPLETO CON OBSERVER Y OBSERVABLE

Basados en las clases de las anteriores secciones relacionadas con objetos tipo OBSERVER y objetos tipo OBSERVABLE, vamos a mostrar un ejemplo completo que muestra el uso de este tipo de clases. Archivo llamado: Observacion.java
import java.awt.*; import java.awt.event.*; public class Observacion extends Frame { public Persona luisfelipe = null; public static EventoModificarPersona evento = null; public Button b1; public TextField caja1; public TextArea ta; public Persona luisfelipe = null; public Observacion () { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); caja1 = new TextField(20); b1 = new Button("Crecer"); Panel panel1 = new Panel(); ta = new TextArea(); evento = new EventoModificarPersona(); // panel1.setLayout(new GridLayout(2,4)); add(panel1); panel1.add(caja1); panel1.add(b1);
panel1.add(ta); luisfelipe = new Persona(); chismoso = new ObservadorPersona(luisfelipe); luisfelipe.addObserver( chismoso ); b1.addActionListener(evento); } public static void main(String args[]) { System.out.println("Starting App"); Observacion f = new Observacion (); f.setSize(200,200); f.setVisible(true); evento.setVentana(f ); chismoso.setVentana(f); }
Archivo llamado: EventoModificarPersona.java

import java.awt.event.*; public class EventoModificarPersona implements ActionListener{ Observacion ventana = null; public void actionPerformed(ActionEvent ev){ if(ev.getSource()==ventana.b1){ int edadcilla = ventana.luisfelipe.getEdad(); ventana.caja1.setText("Edad vista por el evento "+edadcilla); ventana.luisfelipe.crecer(); System.out.println("Ejecutado EVENTO"); } } // Cierra void actionPerformed public void setVentana(Observacion ref){ ventana = ref; } } // Cierra class EventoModificarPersona
Archivo llamado: ObservadorPersona.java

import java.util.Observer; import java.util.Observable; public class ObservadorPersona implements Observer{ private Persona personaObservable=null; private Observacion refVentana; public ObservadorPersona(Persona personaObservable){ this.personaObservable = personaObservable; }
public void update(Observable observable, Object objeto){ if(observable == personaObservable){ this.refVentana.ta.setText("Edad vista por el observador: "+personaObservable.getEdad()); } } public void setVentana(Observacion refVentana){ this.refVentana = refVentana; } } // Cierra class ObservadorPersona
Archivo llamado: Persona.java

import java.util.Observable; public class Persona extends Observable { private int edad; public Persona(){ edad = 0; } public int getEdad(){ return edad; } public void crecer(){ System.out.println("La edad era: "+edad); setEdad(getEdad()+1); System.out.println("La edad ahora es: "+edad); } // Propiedad para asignar el valor de la edad // Las clases que estan pendientes de cambios en edad // son notificadas de dicho cambio. public void setEdad(int edad) { this.edad = edad; setChanged(); notifyObservers(); } } // Cierra class Persona
La ejecucin del anterior programa produce una interfaz similar a la siguiente:
Cuando se hace click sobre el botn con la etiqueta crecer se producen inicialmente los siguientes resultados:
En la cual queda bien claro que el valor antes de ser modificado y visto por el evento es el valor 0, pero el valor visto por el observador es 1, debido a que este observador es notificado del cambio justamente despus de modificado el valor de la variable edad en la clase Persona.
16.6. PREGUNTAS SOBRE OBSERVER Y OBSERVABLE

En esta seccin se muestran una serie de preguntas que pretenden comprobar que tan afianzados han quedado los conocimientos sobre el tema de clases tipo OBSERVER y tipo OBSERVABLE, veamos pues las preguntas:
1. Es posible crear eventos en Java, sin usar las clases que tiene dicho lenguaje para tal fin, simplemente haciendo uso de las clases tipo OBSERVER y OBSERVABLE? 2. Segn lo visto en la seccin sobre OBSERVER y OBSERVABLE es posible que un objeto tipo OBSERVABLE este asociado con varios OBSERVER? 3. Es posible crear un solo objeto OBSERVER que observe a varios objetos OBSERVABLES, pero que dependiendo del objeto que halla sido modificado en su estado se comporte? Si responde afirmativamente a la afirmacin: Cmo hara un programa que implemente dicha funcionalidad? 4. Suponga un programa que tiene una clase que accede a un archivo plano y que dicha clase es usada por varios clientes del aplicativo. Se quiere tener acceso solamente al archivo por parte de un solo usuario y hasta que dicho usuario no halla desocupado y liberado los recursos relacionados con el acceso a dicho archivo no se puede permitir que otro usuario acceda a dicho archivo. Tambin se quiere que la adjudicacin sobre el uso del archivo se entregue por orden de entrada de los diversos usuarios al sistema. Explique mediante un grafico como implementara una solucin de este tipo usando clases tipo OBSERVER y clases tipo OBSERVABLE. 5. Qu otras aplicaciones le ha encontrado a las clases OBSERVER y OBSERVABLE vistas en la unidad?
17. COMO DELEGAR CLASES
17.1. PLANTEAMIENTO TEORICO DE LA DELEGACION

Imagnese por un momento que tengo una clase llamada MAMIFERO, de tal suerte que al momento de su creacin se comporta como si fuera un PERRO. Esto se logra si tenemos una clase llamada ANIMAL que fuerce a que los que sean de este tipo implementen dicha funcionalidad. En trminos de UML podramos colocar esta situacin tal como se muestra en el siguiente diagrama de clases:
ANIMAL expresarse() caminar()
MAMIFERO expresarse() caminar()
Y para lograr que se presente la condicin de inicio que al momento de creacin de un MAMIFERO, este se comporte como si fuese un PERRO, tendramos que hacer un constructor en la clase MAMIFERO que defina una referencia a un objeto de tipo ANIMAL y se lo asigne a un objeto tipo PERRO. En trminos de UML, vamos a colocar el constructor
MAMIFERO expresarse() caminar() Mamifero()
y diremos que el cdigo colocado en mtodo constructor de la clase MAMIFERO ser el siguiente:
public Mamifero() { super(); i=new Perro(); }
Recordemos que la relacin en UML que se coloca es la relacin de realizacin que se simboliza con una flecha punteada y terminada en un triangulo sin rellenar que significa que la clase MAMIFERO implementa la funcionalidad especificada en la clase ANIMAL. Tambien es bueno mencionar que la clase MAMIFERO debe estar asociada con una relacin de dependencia a la clase PERRO. Esto se coloca en UML, mediante el siguiente diagrama:
MAMIFERO expresarse() caminar() Mamifero() PERRO
Recordemos que la relacin es dependencia debido a que la lnea es punteada y la flecha es abierta. No es complicado pensar que la reacion sea de dependencia puesto que el objeto tipo PERRO debe poderse crear antes que se cree el objeto tipo MAMIFERO debido a que esta creacin se especifica en el constructor de la clase MAMIFERO y como es bien sabido, si no se puede ejecutar el constructor, no se puede crear el objeto. De otra parte lo que se pretende hacer es tener un objeto que sea de un tipo por ejemplo en este caso que sea de tipo MAMIFERO y concretamente que se comporte como si fuera un PERRO, pero que en tiempo de ejecucin y en forma dinmica se pueda cambiar su tipo y pueda llegar a ser incluso de tipo HUMANO, lo cual obliga obviamente a que tanto la clase PERRO como la clase ANIMAL deben compartir una cierta funcionalidad y en este caso la funcionalidad compartida se especifica mediante la implementacin de la clase ANIMAL por parte de ambas clases. En pocas palabras tenemos a nivel de UML, la siguiente situacin:
MAMIFERO expresarse() caminar() Mamifero()
PERRO expresarse() caminar()
HUMANO expresarse() caminar()
Ahora bien, queremos que cuando se cambie el tipo de objeto en tiempo de ejecucin este cambio sea lo mas transparente para el sistema. En pocas palabras queremos que el objeto de tipo MAMIFERO pueda invocar un mtodo que lo convierta a un objeto tipo HUMANO y tambin que le permita en un momento dado convertirse nuevamente en un objeto tipo PERRO. Para lograr esta funcionalidad tendramos que definir dos mtodos adicionales en la clase MAMIFERO que permitan hacer estas alteraciones en tiempo de ejecucin y esta situacin a nivel de UML se muestra a continuacin:
MAMIFERO PERRO expresarse() caminar() Mamifero() toPerro() toHombre() expresarse() caminar() HUMANO expresarse() caminar()
En donde los mtodos toPerro y toHombre hagan uso de una variable tipo interfaz por ejemplo llamada i que pueda ser reasignada en tiempo de ejecucin para el caso del mtodo toPerro tal como se muestra a continuacin:
void toPerro() { i = new Perro(); }
y para el metodo toHombre, como sigue en la siguiente lnea:

void toHombre() { i = new Hombre(); }
17.2. EJERCICIO PRCTICO SOBRE DELEGACION

Para lograr la completa comprensin de la seccin anterior sobre la delegacin, vamos a continuacin a mostrar el cdigo completo de una aplicacin que implementa la funcionalidad descrita en el anterior diagrama UML sobre delegacin. Archivo Animal.java
public interface Animal { void expresarse(); void caminar(); }
Archivo Hombre.java
public class Hombre implements Animal { public void expresarse() { System.out.println("Hombre expresarse hablando"); } public void caminar() { System.out.println("Hombre caminando en DOS PIES"); } }
Archivo Main.java
public class Main { public static void main(String[] args) { Mamifero c = new Mamifero(); c.expresarse(); c.caminar(); c.toHombre(); c.expresarse(); c.caminar(); } }
Archivo Mamifero.java
public class Mamifero implements Animal { Animal i ; public Mamifero() { super(); i=new Perro(); } public void expresarse() { i.expresarse(); } public void caminar() { i.caminar(); } // Con estos metodos se puede hacer casting // entre objetos tipo Perro y Hombre void toPerro() { i = new Perro(); } void toHombre() { i = new Hombre(); } }
Archivo Perro.java El cual al ser ejecutado arroja unos resultados similares a los siguientes: Perro expresandose ladrando Perro caminando en DOS PATAS Hombre expresarse hablando Hombre caminando en DOS PIES En donde se puede apreciar que al ejecutar las lneas siguientes:
Mamifero c = new Mamifero(); c.expresarse(); c.caminar(); c.toHombre(); c.expresarse(); c.caminar();
Inicialmente se estaba expresando el PERRO: Perro expresandose ladrando Perro caminando en DOS PATAS y despus de convertirse a HOMBRE invocando el mtodo toHombre(), en verdad estaba actuando un hombre debido a que se obtuvieron las dos ultimas lneas: Hombre expresarse hablando Hombre caminando en DOS PIES
17.3. PREGUNTAS SOBRE DELEGACION

Qu entendi por delegacin? En que casos utilizara la delegacin de clases? Cree que la delegacin puede decrementar el rendimiento de aplicaciones o incrementarlo? Por que? Qu ventajas le ve a la delegacin? Qu desventajas le ve a la delegacin?
18. SERIALIZACION DE OBJETOS

La serializacin de objetos es una parte muy interesante de algunos lenguajes orientados a objetos, en la cual se puede guardar el estado de un objeto en un tiempo determinado.
18.1. SERIALIZAR UN OBJETO COMPLETAMENTE

Para explicar este concepto imaginmonos un objeto que tenga las propiedades y los valores mostrados en la siguiente figura: Int edad = 0;
String nombre = Hugo;
Int numeroAmigos=0
Ahora, imaginmonos que han transcurrido 2 anos y el objeto tiene 3 amigos, tendramos entonces la siguiente situacin: Int edad = 0;
Int edad = 2;
Int numeroAmigos=0
Int numeroAmigos=0
Tiempo 0 NO ALMACENADO
Pensemos que queremos almacenar el estado del objeto en el tiempo 2. Grficamente tendramos la siguiente situacin: Int edad = 0;
Int edad = 2;
Int numeroAmigos=0
Int numeroAmigos=3
Tiempo 2 ALMACENADO
Pensemos que transcurridos 5 anos, el objeto tiene 6 amigos, situacin que puede verse grficamente como se muestra a continuacin:
Int edad = 0;
Int edad = 2;
Int edad = 5;
Int numeroAmigos=0
Int numeroAmigos=3
Int numeroAmigos=6
Tiempo 2 ALMACENADO
Realicemos ahora una recuperacin del objeto, basado en el objeto que se almaceno. Debera imprimirse pues, el objeto almacenado en el tiempo 2, tal como se muestra a continuacin:
edad = 0; nombre = Hugo; numeroAmigos=0 edad = 2; nombre = Hugo; numeroAmigos=3 edad = 5; nombre = Hugo; numeroAmigos=6 edad = 2; nombre = Hugo; numeroAmigos=3
Tiempo 2 ALMACENADO
Tiempo 5 NO ALMACENAO
RECUPERADO DEL TIEMPO 2
En este caso obtenemos una socializacin completa, debido a que todos los elementos contenidos en el objeto fueron almacenados durante el proceso de socializacin y obviamente en el proceso de recuperacin del objeto tambin llamado deserializacin se volvieron a obtener los valores previamente almacenados.
18.2. SERIALIZAR UN OBJETO COMPLETAMENTE EN JAVA

Siguiendo la lgica de la seccin anterior sobre serializacin completa. Veamos en Java como podemos implementar los pasos descritos en la seccin anterior. Primero es bueno tener en cuenta que una clase se puede serializar siempre y cuando implemente la interfaz Serializable. A continuacin se muestra la interfaz: Archivo InterfazSerializable.java
import java.io.*; public interface InterfazSerializable extends Serializable{ }
Y posteriormente el objeto que implementa esta interfaz: Archivo ClaseSerializable.java

public class ClaseSerializable implements InterfazSerializable{ public int edad; public String nombre; public int numeroAmigos; public ClaseSerializable(String nombrecin){ this.nombre = nombrecin; edad = 0; numeroAmigos = 0; } public void crecer(int valor){ edad = valor; } public void imprimirDatosClase(){ System.out.println("edad = "+edad); System.out.println("nombre = "+nombre); System.out.println("numeroAmigos = "+numeroAmigos); } public void conseguirAmigos(int numero){ this.numeroAmigos = numero; } }
En trminos de UML tenemos la siguiente situacin:

InterfazSeriali zable
<<Serializable>> ClaseSerializable int edad String nombre int numeroAmigos crecer(int valor) imprimirDatosClase() conseguirAmigos(int numero)
Ahora tan solo resta mostrar el programa que crea un objeto de la clase ClaseSerializable lo usa: Archivo MyApp1.java
import java.io.*; import java.awt.*; import java.awt.event.*; public class MyApp1 { ClaseSerializable objeto1 = null; public MyApp1() { objeto1 = new ClaseSerializable("Hugo"); System.out.println("Datos iniciales del objeto"); objeto1.imprimirDatosClase(); try{ // Creamos los flujos para leer y escribir en archivo.txt
FileOutputStream flujoSalida = new FileOutputStream("archivo.txt"); FileInputStream flujoEntrada = new FileInputStream("archivo.txt"); ObjectOutputStream escritor = new ObjectOutputStream(flujoSalida); ObjectInputStream lector = new ObjectInputStream(flujoEntrada);
// Transcurridos dos anos el objeto ha crecido y ha conocido // tres amigos // Lo hacemos crecer y lo imprimimos
System.out.println("Transcurridos dos anos el objeto ha crecido");
System.out.println("y ha conocido 3 amigos"); objeto1.crecer(2); objeto1.conseguirAmigos(3);
objeto1.imprimirDatosClase(); // Escribimos el objeto en archivo.txt System.out.println("Escribimos el objeto en archivo.txt"); escritor.writeObject(objeto1); // Transcurridos 5 anos el objeto ha crecido // Lo hacemos crecer 5 anos y lo imprimimos. // Tambien haremos que tenga 6 amigos System.out.println("Transcurridos 5 anos el objeto ha crecido"); System.out.println("y ha conocido 6 amigos"); objeto1.crecer(5); objeto1.conseguirAmigos(6); objeto1.imprimirDatosClase(); // Recuperamos el objeto System.out.println("Recuperamos el objeto"); objeto1 = (ClaseSerializable)lector.readObject(); // Imprimimos objeto recuperado System.out.println("Imprimimos objeto recuperado"); objeto1.imprimirDatosClase(); } catch(Exception e){ System.out.println("Errores en algo"); } } public static void main(String args[]) { MyApp1 f = new MyApp1(); } }
En el anterior programa podemos ver primero se crea un objeto en tiempo 0, despus en el tiempo 2 se alteran sus valores y se almacena, en el tiempo 5 se alteran sus valores, pero no se almacena y finalmente en el siguiente tiempo se recupera, con lo cual se deberan ver los valores del objeto que fue guardado en el tiempo 2.
edad = 0; nombre = Hugo; numeroAmigos=0 edad = 2; nombre = Hugo; numeroAmigos=3 edad = 5; nombre = Hugo; numeroAmigos=6 edad = 2; nombre = Hugo; numeroAmigos=3
Tiempo 2 ALMACENADO
Tiempo 5 NO ALMACENAO
RECUPERADO DEL TIEMPO 2
Finalmente para probar que la lgica funciona para el programa que estamos mostrando, simplemente vamos a decir que los resultados arrojados por el programa anterior son los siguientes: Datos iniciales del objeto edad = 0 nombre = Hugo numeroAmigos = 0 Transcurridos dos anos el objeto ha crecido y ha conocido 3 amigos edad = 2 nombre = Hugo numeroAmigos = 3 Escribimos el objeto en archivo.txt Transcurridos 5 anos el objeto ha crecido y ha conocido 6 amigos edad = 5 nombre = Hugo numeroAmigos = 6 Recuperamos el objeto Imprimimos objeto recuperado edad = 2 nombre = Hugo numeroAmigos = 3 Exit code: 0 No Errors
En donde se observa que los datos iniciales del objeto eran: Datos iniciales del objeto edad = 0 nombre = Hugo numeroAmigos = 0 Fruto de crear el objeto tan solo con el valor de Hugo en el atributo nombre y de ejecutar las sentencias siguientes:
objeto1 = new ClaseSerializable("Hugo"); System.out.println("Datos iniciales del objeto"); objeto1.imprimirDatosClase();
Transcurridos dos anos el objeto ha crecido y ha conocido 3 amigos

System.out.println("y ha conocido 3 amigos"); objeto1.crecer(2); objeto1.conseguirAmigos(3); objeto1.imprimirDatosClase();
lo cual produce el resultado: Transcurridos dos anos el objeto ha crecido y ha conocido 3 amigos edad = 2 nombre = Hugo numeroAmigos = 3 Procedemos pues a guardar los datos del objeto usando la instruccin:
// Escribimos el objeto en archivo.txt System.out.println("Escribimos el objeto en archivo.txt"); escritor.writeObject(objeto1);
Con lo cual los siguientes datos son guardados edad = 2 nombre = Hugo numeroAmigos = 3 DATOS ALMACENADOS USANDO SERIALIZACION
Transcurridos 5 anos el objeto ha crecido y ha conocido 6 amigos, lo cual se hace con las instrucciones:
// Transcurridos 5 anos el objeto ha crecido // Lo hacemos crecer 5 anos y lo imprimimos. // Tambien haremos que tenga 6 amigos System.out.println("Transcurridos 5 anos el objeto ha crecido"); System.out.println("y ha conocido 6 amigos"); objeto1.crecer(5); objeto1.conseguirAmigos(6); objeto1.imprimirDatosClase();
Y produce el resultado siguiente: edad = 5 nombre = Hugo numeroAmigos = 6
Despues restauramos los datos del objeto serializado y lo imprimimos usando las instrucciones:
// Recuperamos el objeto System.out.println("Recuperamos el objeto"); objeto1 = (ClaseSerializable)lector.readObject(); // Imprimimos objeto recuperado System.out.println("Imprimimos objeto recuperado"); objeto1.imprimirDatosClase();
Las cuales producen el resultado siguiente: edad = 2 nombre = Hugo numeroAmigos = 3 DATOS RECUPARADOS DE LA SERIALIZACION
18.3. ATRIBUTOS TRANSIENTES EN LA SERIALIZACION

Bsicamente un objeto puede contener atributos transientes y atributos no transientes. El valor de los atributos transientes no es almacenado en el momento de la serializacin del objeto y por tanto se pierde. Para comprender esto haremos una modificacin a la ClaseSerializable de la seccin anterior, en donde el atributo numeroAmigos dejara de ser declarada como se muestra en el siguiente diagrama:
<<Serializable>> ClaseSerializable int edad String nombre int numeroAmigos crecer(int valor) imprimirDatosClase() conseguirAmigos(int numero)
Y se declarar de tipo transient, con lo cual nuestro diagrama de clases toma la siguiente forma:
<<Serializable>> ClaseSerializable int edad String nombre transient int numeroAmigos crecer(int valor) imprimirDatosClase() conseguirAmigos(int numero)
Y nuestra clase ClaseSerializable tendr las siguientes instrucciones:

public class ClaseSerializable implements InterfazSerializable{ public int edad; public String nombre; public transient int numeroAmigos; public ClaseSerializable(String nombrecin){ this.nombre = nombrecin; edad = 0; numeroAmigos = 0; } public void crecer(int valor){ edad = valor; } public void imprimirDatosClase(){ System.out.println("edad = "+edad); System.out.println("nombre = "+nombre); System.out.println("numeroAmigos = "+numeroAmigos); } public void conseguirAmigos(int numero){ this.numeroAmigos = numero; } }
Ahora supongamos que estamos usando la misma clase interfaz de la seccin anterior, es decir que estamos usando el archivo mostrado a continuacin:
Archivo InterfazSerializable.java
Si ejecutamos un programa que haga uso de un objeto que sea del tipo ClaseSerializable y que puede ser un programa como el mostrado en las siguientes lneas: Archivo MyApp1.java
import java.io.*; import java.awt.*; import java.awt.event.*; public class MyApp1 { ClaseSerializable objeto1 = null; public MyApp1() { objeto1 = new ClaseSerializable("Hugo"); System.out.println("Datos iniciales del objeto"); objeto1.imprimirDatosClase(); try{ // Creamos los flujos para leer y escribir en archivo.txt
// Transcurridos dos anos el objeto ha crecido y ha conocido // tres amigos // Lo hacemos crecer y lo imprimimos
System.out.println("y ha conocido 3 amigos"); objeto1.crecer(2); objeto1.conseguirAmigos(3); objeto1.imprimirDatosClase(); // Escribimos el objeto en archivo.txt System.out.println("Escribimos el objeto en archivo.txt"); escritor.writeObject(objeto1); // Transcurridos 5 anos el objeto ha crecido // Lo hacemos crecer 5 anos y lo imprimimos. // Tambien haremos que tenga 6 amigos System.out.println("Transcurridos 5 anos el objeto ha crecido"); System.out.println("y ha conocido 6 amigos"); objeto1.crecer(5); objeto1.conseguirAmigos(6); objeto1.imprimirDatosClase();
// Recuperamos el objeto System.out.println("Recuperamos el objeto"); objeto1 = (ClaseSerializable)lector.readObject(); // Imprimimos objeto recuperado System.out.println("Imprimimos objeto recuperado"); objeto1.imprimirDatosClase(); } catch(Exception e){ System.out.println("Errores en algo"); } } public static void main(String args[]) { MyApp1 f = new MyApp1(); } }
Podemos encontrar que los resultados obtenidos fueron los siguientes: Datos iniciales del objeto edad = 0 nombre = Hugo numeroAmigos = 0 Transcurridos dos anos el objeto ha crecido y ha conocido 3 amigos edad = 2 nombre = Hugo numeroAmigos = 3 Escribimos el objeto en archivo.txt Transcurridos 5 anos el objeto ha crecido y ha conocido 6 amigos edad = 5 nombre = Hugo numeroAmigos = 6 Recuperamos el objeto Imprimimos objeto recuperado edad = 2 nombre = Hugo numeroAmigos = 0 Exit code: 0 No Errors
En donde es claro que a pesar que el objeto objeto1 se guardo cuando tena los siguientes valores: edad = 2 nombre = Hugo numeroAmigos = 3 Tambin es cierto que al deserializarse se obtienen los siguientes datos: edad = 2 nombre = Hugo numeroAmigos = 0 Lo que indica que el atributo numeroAmigos no fue almacenado en el momento de la serializacin
18.4. LA SERIALIZACION Y EL DIAGRAMA DE ESTADOS

El diagrama de estados en UML intenta modelar los diversos estados por los que pasa un objeto en el tiempo. De otra parte los estados tienen directa relacin con el contenido de los atributos de un objeto, es decir que podemos pensar que un objeto cambia de estado cuando algunos de sus atributos han cambiado de valor. De otra parte es interesante observar que la serializacin intenta almacenar el estado de un objeto en un momento determinado y que la deserializacin intenta retroceder en el tiempo a un objeto restableciendo los valores que sus atributos no transient tenan en un determinado momento. Es interesante observar que cuando el objeto objeto1 tena los valores: edad = 0 nombre = Hugo numeroAmigos = 0 Se podra modelar esta situacin con el diagrama UML:
PRENATAL
Pero tambin es posible que cuando el objeto objeto1 cambie sus valores a los siguientes: edad = 2 nombre = Hugo numeroAmigos = 3
Se podra modelar este nuevo estado de la siguiente manera:

BEBE
Y la transicin de un estado al otro se podra modelar de la siguiente forma:

PRENATAL BEBE
En donde el paso de un estado a otro depende no del numero de amigos que tenga el objeto, sino de la edad del objeto. Tambien podramos pensar en modelar la situacin que el objeto objeto1 tenga los siguientes datos: edad = 5 nombre = Hugo numeroAmigos = 6 Mediante el empleo de la siguiente notacin:
NINO
Con lo cual la alteracin de estos atributos del objeto objeto1 hechas hasta el momento podran modelarse de la siguiente manera:
PRENATAL BEBE
NINO
Y nos restara modelar la situacin en la que se puede pasar al estado anterior, o sea del estado de NINO al estado de BEBE usando la descerializacion y modelndolo tal como se muestra a continuacin:
PRENATAL
BEBE
NINO
Finalmente si el estado inicial es ser PRENATAL y el mximo estado es ser NINO teniendo en cuenta que utpicamente solamente se pueda morir cuando se sea NINO, podramos modelar esta situacin tal como se muestra a continuacin:
PRENATAL
BEBE
NINO
Obviamente el anterior diagrama no es acorde con la realidad debido a que un PRENATAL se puede morir, al igual que un BEBE o un NINO. Con lo cual en la vida real tenemos una situacin como la siguiente:
PRENATAL BEBE
NINO
Aunque para el caso del programa que ya hicimos y que mostramos anteriormente tan solo podemos finalizar si somos NINO.
18.4. TALLER PROPUESTO SOBRE SERIALIZACION

Con el animo de lograr que los conceptos de serializacin queden bien comprendidos por parte del amigo lector / estudiante, a continuacin se muestra un ejercicio propuesto sobre serializacin en el que el estudiante debe explicar por que el siguiente programa conformado por los tres archivos ClaseSerializable.java, InterfazSerializable y MyApp.java produce los resultados aqu expuestos. Los tres archivos del programa son: Archivo InterfazSerializable.java
Archivo ClaseSerializable.java
public class ClaseSerializable implements InterfazSerializable{ public int edad; public String nombre; public transient int numeroAmigos; public ClaseSerializable(String nombrecin){ this.nombre = nombrecin; edad = 0;
numeroAmigos = 0;
public void crecer(int valor){ edad = valor; } public void imprimirDatosClase(){ System.out.println("edad = "+edad); System.out.println("nombre = "+nombre); System.out.println("numeroAmigos = "+numeroAmigos); } public void conseguirAmigos(int numero){ this.numeroAmigos = numero; } }
Y el archivo: Archivo MyApp.java

import java.io.*; import java.awt.*; import java.awt.event.*; public class MyApp { ClaseSerializable ClaseSerializable ClaseSerializable ClaseSerializable public MyApp() { objeto1 = new objeto2 = new objeto3 = new objeto4 = new
objeto1 objeto2 objeto3 objeto4
= = = =
null; null; null; null;
ClaseSerializable("Hugo"); ClaseSerializable("Paco"); ClaseSerializable("Luis"); ClaseSerializable("Mickey");
// Imprimimos los datos iniciales de los objetos System.out.println("Datos iniciales de objetos"); objeto1.imprimirDatosClase(); objeto2.imprimirDatosClase(); objeto3.imprimirDatosClase(); objeto4.imprimirDatosClase(); try{ // Creamos los flujos para leer y escribir en archivo.txt
// Escribimos los objetos en archivo.txt System.out.println("Escribimos los objetos en archivo.txt"); escritor.writeObject(objeto1); escritor.writeObject(objeto2); escritor.writeObject(objeto3); escritor.writeObject(objeto4); // Transcurridos dos anos los objetos han crecido
System.out.println("Transcurridos dos anos los objetos han crecido");
objeto1.crecer(2); objeto2.crecer(2); objeto3.crecer(2); objeto4.crecer(2); // Imprimimos los nuevos datos de los objetos System.out.println("Imprimimos los nuevos datos de los objetos"); objeto1.imprimirDatosClase(); objeto2.imprimirDatosClase(); objeto3.imprimirDatosClase(); objeto4.imprimirDatosClase();
System.out.println("Y uno de ellos el mas piloso ha conseguido 3 amigos");
// Y uno de ellos el mas piloso ha conseguido 3 amigos objeto3.conseguirAmigos(3);
// Imprimimos nuevamente datos de los objetos System.out.println("Imprimimos nuevamente datos de los objetos"); objeto1.imprimirDatosClase(); objeto2.imprimirDatosClase(); objeto3.imprimirDatosClase(); objeto4.imprimirDatosClase(); // Volvemos a serializar los objetos System.out.println("Volvemos a serializar los objetos"); escritor.writeObject(objeto1); escritor.writeObject(objeto2); escritor.writeObject(objeto3); escritor.writeObject(objeto4); // Recuperamos los objetos una vez System.out.println("Recuperamos los objetos una vez"); objeto1 = (ClaseSerializable)lector.readObject(); objeto2 = (ClaseSerializable)lector.readObject(); objeto3 = (ClaseSerializable)lector.readObject(); objeto4 = (ClaseSerializable)lector.readObject(); // Falta Imprimir objetos recuperados una vez System.out.println("Falta Imprimir objetos recuperados una vez"); objeto1.imprimirDatosClase(); objeto2.imprimirDatosClase(); objeto3.imprimirDatosClase(); objeto4.imprimirDatosClase(); // Recuperamos los objetos por segunda vez System.out.println("Recuperamos los objetos por segunda vez"); objeto1 = (ClaseSerializable)lector.readObject(); objeto2 = (ClaseSerializable)lector.readObject();
objeto3 = (ClaseSerializable)lector.readObject(); objeto4 = (ClaseSerializable)lector.readObject(); // Falta Imprimir objetos recuperados segunda vez
System.out.println("Falta Imprimir objetos recuperados segunda vez");
objeto1.imprimirDatosClase(); objeto2.imprimirDatosClase(); objeto3.imprimirDatosClase(); objeto4.imprimirDatosClase(); // Recuperamos el objeto 3 System.out.println("Recuperamos el objeto 3"); objeto1 = (ClaseSerializable)lector.readObject(); objeto2 = (ClaseSerializable)lector.readObject(); objeto3 = (ClaseSerializable)lector.readObject(); objeto4 = (ClaseSerializable)lector.readObject(); // Falta Imprimir objeto3 recuperado System.out.println("Falta Imprimir objeto3 recuperado"); objeto3.imprimirDatosClase();
} catch(Exception e){ System.out.println("Errores en algo"); }
} public static void main(String args[]) { MyApp f = new MyApp(); } }
Los cuales producen el resultado siguiente: Datos iniciales de objetos edad = 0 nombre = Hugo numeroAmigos = 0 edad = 0 nombre = Paco numeroAmigos = 0 edad = 0 nombre = Luis numeroAmigos = 0 edad = 0 nombre = Mickey numeroAmigos = 0 Escribimos los objetos en archivo.txt Transcurridos dos anos los objetos han crecido
Imprimimos los nuevos datos de los objetos edad = 2 nombre = Hugo numeroAmigos = 0 edad = 2 nombre = Paco numeroAmigos = 0 edad = 2 nombre = Luis numeroAmigos = 0 edad = 2 nombre = Mickey numeroAmigos = 0 Y uno de ellos el mas piloso ha conseguido 3 amigos Imprimimos nuevamente datos de los objetos edad = 2 nombre = Hugo numeroAmigos = 0 edad = 2 nombre = Paco numeroAmigos = 0 edad = 2 nombre = Luis numeroAmigos = 3 edad = 2 nombre = Mickey numeroAmigos = 0 Volvemos a serializar los objetos Recuperamos los objetos una vez Falta Imprimir objetos recuperados una vez edad = 0 nombre = Hugo numeroAmigos = 0 edad = 0 nombre = Paco numeroAmigos = 0 edad = 0 nombre = Luis numeroAmigos = 0 edad = 0 nombre = Mickey numeroAmigos = 0 Recuperamos los objetos por segunda vez Falta Imprimir objetos recuperados segunda vez edad = 0 nombre = Hugo numeroAmigos = 0
edad = 0 nombre = Paco numeroAmigos = 0 edad = 0 nombre = Luis numeroAmigos = 0 edad = 0 nombre = Mickey numeroAmigos = 0 Recuperamos el objeto 3 Errores en algo Exit code: 0 No Errors Y el amigo lector / estudiante debe dar una explicacin racional y cierta sobre la razn por la cual se producen los resultados anteriores.
19. EJERCICIOS QUE TIENEN DIAGRAMAS DE SECUENCIA
19.1. MODELAMIENTO DE DETENCION SINCRONICA DE MULTIPLES HILOS CON UN EJEMPLO.

Supongamos que tenemos un Zoolgico que tiene Burros, perros y como mnimo un Domador. Se requiere que el Zoolgico no solo use los Burros o los Perros, sino que los tenga, debido a que si no los tiene pues no seria un Zoolgico. (Bueno, esto es para el ejercicio, porque los zoolgicos por lo general tienen panteras, leones y otros animales, pero es simplemente para hacer el ejercicio mas sencillo). Segn lo establecido anteriormente podemos decir que las relaciones anteriormente citadas se pueden expresar mediante el siguiente diagrama:
<<include>>
Burro
Zoologico
<<include>>
<<include>>
Perro
Domador
Ahora supongamos que el Zoolgico ha comprado dos burros llamados higor y corcelin, como tambin ha comprado dos perros llamados doki y cuchufleto. Con lo cual nuestro diagrama de clases, podra eventualmente tener algunos objetos tal como se muestra a continuacin:
<<include>> Burro Burro: higor
Zoologico
<<include>> Burro: corcelin Perro <<include>> Perro: doki
Domador
Perro: cuchufleto
Observe amigo lector / estudiante que el smbolo:
Perro
Perro: cuchufleto
No solamente se usa para denotar que una clase dependa de otra, sino que tambin se usa para denotar relaciones de instanciacin entre clases y los objetos que implementan estas clases. En otras palabras vemos que esto es una relacin de instanciacin. Siguiendo con nuestro ejemplo supongamos que el Zoolgico contrata a un domador llamado pepito para que haga el trabajo de adiestrar a estos animalitos, con lo cual nuestro diagrama tomara la siguiente forma:
<<include>> Burro Burro: higor
Zoologico
<<include>> Burro: corcelin
<<include>>
Perro
Perro: doki
Domador
Domador: pepito
Perro: cuchufleto
En trminos de cdigo, las relaciones anteriores se crean cuando se crean los objetos, tal como lo muestra el siguiente cdigo fuente:
Burro higor = new Burro("higor"); Burro corcelin = new Burro("corcelin"); Perro doki = new Perro("doki"); Perro cuchufleto = new Perro("cuchufleto"); Domador pepito = new Domador();
Dado que los animales burros y los perros se comportan abstractamente de acuerdo al concepto de animal, es bueno crear una interfaz que obligue a los animales a implementar su mtodo dialogar (). Con la creacin de esta interfaz, tenemos que nuestro nuevo diagrama de clases toma la forma:
Animal dialogar() <<include>> Burro Burro: higor
Zoologico
<<include>> Burro: corcelin
<<include>>
Perro
Perro: doki
Domador
Domador: pepito
Perro: cuchufleto
Con lo cual queda bien claro que los burros y los perros implementan los contratos especificados en la interfaz Animal. A nivel de cdigo podramos crear la interfaz como se muestra a continuacin:
public interface Animal { public void dialogar(); } // Cierra interface Animal
La clase Perro que implementa la interfaz seria similar a la siguiente:

public class Perro implements Animal{ String nombrecin =""; boolean estadoLadro = true; public void dialogar(){ System.out.println("ladro bastante"); } // Cierra void dialogar() public Perro(String nombre){ nombrecin = nombre; } // Cierra public Perro()
public String getNombre(){ return nombrecin; } } // Cierra class Perro
Y la clase Burro que implementa la interfaz tendra un cdigo similar al siguiente:

public class Burro implements Animal{ String nombrecin =""; boolean estadoRebusno = true; public void dialogar(){ System.out.println("Rebusno bastante"); } // Cierra void dialogar() public Burro(String nombre){ nombrecin = nombre; } // Cierra public Burro() public String getNombre(){ return nombrecin; } } // Cierra class Burro
Con lo cual el diagrama que estamos haciendo tomara una forma similar a la siguiente:
<<include>> Zoologico <<include>> <<include>> Animal dialogar() Domador Perro: doki Burro dialogar() String getNombre() Burro: corcelin Burro: higor
Perro Domador: pepito dialogar() String getNombre() Perro: cuchufleto
De otra parte el zoolgico tiene dos grandes actividades que son las actividades previas a la funcin y las actividades que realiza cuando la funcin esta presentndose. Por esta razn es necesario agregar a la clase zoolgico dos mtodos que son:
Zoologico realizarActividadesPrevias() mostrarFuncion()
Las actividades previas tienen que ver con adiestrar los animales por parte del Domador, en este caso por parte de pepito, con lo cual a nivel de cdigo tendramos un cdigo similar al siguiente:
public void realizarActividadesPrevias(){ pepito.adiestrar(higor); pepito.adiestrar(corcelin); pepito.adiestrar(doki); pepito.adiestrar(cuchufleto); } // Cierra void realizarActividadesPrevias()
En este caso el mtodo adiestrar() del domador es un mtodo que se encuentra dos veces implementado debido a que permite recibir dos tipos de objetos y de acuerdo a cada uno de ellos sigue el proceso de adiestramiento, puesto que no es lo mismo adiestrar un perro que un burro. De otra parte tenemos que el domador es el nico que conoce cuantos animales tiene a su cargo, con lo cual el tendr un vector que permita almacenar los burros y los perros y la implementacin de sus mtodos adiestrar(), seria similar a la siguiente:
public void adiestrar(Burro animalin){ ThreadBurros hiloBurros = new ThreadBurros(animalin, grupoBurros,animalin.getNombre()); vectorBurros.add(hiloBurros); } // Cierra void adiestrar(Burro) public void adiestrar(Perro animalin){ ThreadPerros hiloPerros = new ThreadPerros(animalin, grupoPerros,animalin.getNombre()); vectorPerros.add(hiloPerros); } // Cierra void adiestrar(Perro)
Observemos este proceso de sincronizacin. Vemos que cuando se adiestran a los animales se tienen grupos para cada animal. Veamos la implementacin pues de cada uno de estos ThreadGroup:
ThreadBurros.java public class ThreadBurros extends Thread{ Burro objetoBurro1; public ThreadBurros(Burro objetoBurro, ThreadGroup grupo, String cadena){ super(grupo, cadena); objetoBurro1 = objetoBurro; } // Cierra constructor ThreadBurros public void run(){ while(true){ try{ this.objetoBurro1.dialogar(); Thread.sleep(1000); } // Cierra try catch(Exception e){ System.out.println("Errores rebusnando"); break; // objetoBurro1.estadoRebusnado(false); } // Cierra catch(); } // Cierra while(true) } // Cierra public void run() } // Cierra public class ThreadBurros En donde simplemente se esta diciendo que un burro cuando comienza a dialogar(), lo hace cada Segundo y si en algun momento algun proceso extrano o ajeno no permite la ejecucion, automaticamente se sale del ciclo para que nunca vuelva ejecutarse el hilo. La implementacin para el ThreadPerros es similar a la anterior y se muestra a continuacin: public class ThreadPerros extends Thread{ Perro objetoPerro1; public ThreadPerros(Perro objetoPerro, ThreadGroup grupo, String cadena){ super(grupo, cadena); objetoPerro1 = objetoPerro; } // Cierra constructor ThreadPerros public void run(){ while(true){ try{ this.objetoPerro1.dialogar(); Thread.sleep(1000); } // Cierra try catch(Exception e){ System.out.println("Errores ladrando");
break; } // Cierra catch(); } // Cierra while(true) } // Cierra public void run() } // Cierra public class ThreadPerros Con todo lo dicho hasta el momento, tenemos que nuestro diagrama tiene una forma similar a la siguiente:
<<include>> Zoologico realizarActividadesPrevias() mostrarFuncion() <<include>> <<include>> Animal dialogar() Domador ThreadPerros ThreadBurros Burro: higor
Burro dialogar() String getNombre()
Burro: corcelin
Perro Domador: pepito dialogar() String getNombre() Perro: doki
Perro: cuchufleto
Cuando se pongan a hablar los perros, se obtienen los hilos asociados a cada animal y se comienza la ejecucin del hilo, tal como lo muestran las funciones: ponerHablarBurros() ponerHablarPerros() Las cuales se detallan una a una mas adelante. La funcin ponerHablarBurro, por ejemplo contiene el siguiente cdigo: public void ponerHablarBurros(){ int cantidad = vectorBurros.size(); System.out.println("Cantidad burros = "+cantidad); int contador = 0; while(contador<cantidad){ ThreadBurros grupoBurrosHilos = (ThreadBurros)vectorBurros.elementAt(contador);
try{ grupoBurrosHilos.start(); } catch(Exception e){ System.out.println("Burros no pueden rebusnar"); }// Cierra catch contador++; } // Cierra while } // Cierra void ponerHablarBurros() Es tan complicado hacer este mtodo, que es bueno disear un diagrama que permita modelar la complejidad de dicho mtodo. Para lograr esto, a continuacin se muestra el diagrama de actividad que modela y explica el funcionamiento de dicho mtodo:
v ectorBurros : Vector
obj Sistema : Sistema
grupoBurros : ThreadBurros
<<<<size>>>> obtenerTamano
<<<<println>>>> ImprimirTamano <<<<Max 2>>>> While( contador<2 ) <<<<elementAt>>>> ...>> obtenerElemento <<<<Casting>>>> Conversion
While
<<<<start>>>> ComenzarEjecu cion
Exception?
NO_Exception( e )
SI_Exception( e )
<<<<println>>>> imprimirError
Obviamente el diagrama de actividad para el mtodo ponerHablarPerros, es similar al anterior, pero antes de mostrarlo primero veamos el cdigo fuente de dicho mtodo: public void ponerHablarPerros(){ int cantidad = vectorPerros.size(); System.out.println("Cantidad perros = "+cantidad); int contador = 0; while(contador<cantidad){ ThreadPerros grupoPerrosHilos = (ThreadPerros)vectorPerros.elementAt(contador); try{ grupoPerrosHilos.start(); } catch(Exception e){ System.out.println("Perros no pueden ladrar"); }// Cierra catch contador++; } // Cierra while } // Cierra void ponerHablarPerros()
Ahora el diagrama de actividad asociado a dicho mtodo:
v ectorPerros : Vector
obj Sistema : Sistema
grupoPerros : ThreadPerros
<<<<size>>>> obtenerTamano
<<<<println>>>> ImprimirTamano <<<<Max 2>>>> While( contador<2 ) <<<<elementAt>>>> ...>> obtenerElemento <<<<Casting>>>> Conversion
While
<<<<start>>>> ComenzarEjecu cion
Exception?
NO_Exception( e )
SI_Exception( e )
<<<<println>>>> imprimirError
La detencin de los procesos simultneos se hace mediante los siguientes mtodos: public void callarBurros(){ try{ System.out.println("Estoy intentando interrumpir"); grupoBurros.interrupt(); System.out.println("PUDE interrumpir a burros"); } catch(Exception e){ System.out.println("No pude callar a Burros"); } // Cierra catch } // Cierra void callarBurros El cual detiene la ejecucin del mtodo dialogar, asociado a cada Burro, Y para el caso de detener los hilos asociados a los Perros, tenemos el siguiente cdigo: public void callarPerros(){ try{ System.out.println("Estoy intentando interrumpir"); grupoPerros.interrupt(); System.out.println("PUDE interrumpir a perros"); } catch(Exception e){ System.out.println("No pude callar a Perros"); } // Cierra catch } // Cierra callarPeros() Observe finalmente que la invocacin del mtodo interrupt() se encarga de detener los hilos asociados a este ThreadGroup. En conclusin todos los hilos que se encuentran en este grupo de hilos, son automticamente detenidos con la invocacin de este mtodo.
19.2. IMPLEMENTACION DE DETENCION SINCRONICA DE MULTIPLES HILOS CON UN EJEMPLO.

Basados en el ejercicio de la anterior seccin, a continuacin mostramos el cdigo fuente en java de cada uno de los archivos que conformaran la solucin de software del ejercicio en mencin. Archivo: Anima.java public interface Animal { public void dialogar(); } // Cierra interface Animal Archivo: Burro.java public class Burro implements Animal{ String nombrecin ="";
boolean estadoRebusno = true; public void dialogar(){ System.out.println("Rebusno bastante"); } // Cierra void dialogar() public Burro(String nombre){ nombrecin = nombre; } // Cierra public Burro() public String getNombre(){ return nombrecin; } } // Cierra class Burro Archivo Domador.java import java.util.*; public class Domador { ThreadGroup grupoPerros = new ThreadGroup("perrillos"); ThreadGroup grupoBurros = new ThreadGroup("burrillos"); Vector vectorBurros = new Vector(); Vector vectorPerros = new Vector(); public void callarAnimales(){ callarBurros(); callarPerros(); } // Cierra void callarAnimales() public void adiestrar(Burro animalin){
ThreadBurros hiloBurros = new ThreadBurros(animalin, grupoBurros,animalin.getNombre());
vectorBurros.add(hiloBurros); } // Cierra void adiestrar(Burro) public void adiestrar(Perro animalin){

ThreadPerros hiloPerros = new ThreadPerros(animalin, grupoPerros,animalin.getNombre());
vectorPerros.add(hiloPerros); } // Cierra void adiestrar(Perro) public void ponerHablarBurros(){ int cantidad = vectorBurros.size(); System.out.println("Cantidad burros = "+cantidad); int contador = 0; while(contador<cantidad){
ThreadBurros grupoBurrosHilos = (ThreadBurros)vectorBurros.elementAt(contador);
try{
// Thread.sleep(500); grupoBurrosHilos.start(); } catch(Exception e){ System.out.println("Burros no pueden rebusnar"); }// Cierra catch contador++; } // Cierra while } // Cierra void ponerHablarBurros() public void ponerHablarPerros(){ int cantidad = vectorPerros.size(); System.out.println("Cantidad perros = "+cantidad); int contador = 0; while(contador<cantidad){ ThreadPerros grupoPerrosHilos = (ThreadPerros)vectorPerros.elementAt(contador); try{ // Thread.sleep(500); grupoPerrosHilos.start(); } catch(Exception e){ System.out.println("Perros no pueden ladrar"); }// Cierra catch contador++; } // Cierra while } // Cierra void ponerHablarPerros() public void callarBurros(){ try{ System.out.println("Estoy intentando interrumpir"); grupoBurros.interrupt(); System.out.println("PUDE interrumpir a burros"); } catch(Exception e){ System.out.println("No pude callar a Burros"); } // Cierra catch } // Cierra void callarBurros public void callarPerros(){ try{ System.out.println("Estoy intentando interrumpir"); grupoPerros.interrupt(); System.out.println("PUDE interrumpir a perros"); }
catch(Exception e){ System.out.println("No pude callar a Perros"); } // Cierra catch } // Cierra callarPeros()
} // Cierra class Domador Archivo Perro.java public class Perro implements Animal{ String nombrecin =""; boolean estadoLadro = true; public void dialogar(){ System.out.println("ladro bastante"); } // Cierra void dialogar() public Perro(String nombre){ nombrecin = nombre; } // Cierra public Perro() public String getNombre(){ return nombrecin; } } // Cierra class Perro Archivo ThreadBurros.java public class ThreadBurros extends Thread{ Burro objetoBurro1; public ThreadBurros(Burro objetoBurro, ThreadGroup grupo, String cadena){ super(grupo, cadena); objetoBurro1 = objetoBurro; } // Cierra constructor ThreadBurros public void run(){ while(true){ try{ this.objetoBurro1.dialogar(); Thread.sleep(1000); } // Cierra try catch(Exception e){ System.out.println("Errores rebusnando"); break; // objetoBurro1.estadoRebusnado(false); } // Cierra catch();
} // Cierra while(true) } // Cierra public void run() } // Cierra public class ThreadBurros Archivo ThreadPerros.java public class ThreadPerros extends Thread{ Perro objetoPerro1; public ThreadPerros(Perro objetoPerro, ThreadGroup grupo, String cadena){ super(grupo, cadena); objetoPerro1 = objetoPerro; } // Cierra constructor ThreadPerros public void run(){ while(true){ try{ this.objetoPerro1.dialogar(); Thread.sleep(1000); } // Cierra try catch(Exception e){ System.out.println("Errores ladrando"); break; } // Cierra catch(); } // Cierra while(true) } // Cierra public void run() } // Cierra public class ThreadPerros Archivo Zoologico.java public class Zoologico { Burro higor = new Burro("higor"); Burro corcelin = new Burro("corcelin"); Perro doki = new Perro("doki"); Perro cuchufleto = new Perro("cuchufleto"); Domador pepito = new Domador(); public void realizarActividadesPrevias(){ pepito.adiestrar(higor); pepito.adiestrar(corcelin); pepito.adiestrar(doki); pepito.adiestrar(cuchufleto); } // Cierra void realizarActividadesPrevias() public void mostrarFuncion(){
pepito.ponerHablarBurros(); pepito.ponerHablarPerros(); try{ Thread.sleep(7000); pepito.callarAnimales(); } catch(Exception e){ System.out.println("Errores callando burros o perros"); } } // Cierra mostrarFuncion() public static void main(String[] args) { Zoologico programa = new Zoologico(); programa.realizarActividadesPrevias(); programa.mostrarFuncion(); } // Cierra statico void main() } // Cierra class Zoologico
20. INTRODUCCION A LOS PATRONES DE SOFTWARE

Una primera clasificacin de los patrones es de acuerdo con las siguientes funcionalidades: Funcionalidad de creacin Funcionalidad estructural Funcionalidad de comportamiento
20.1. PATRONES CON FUNCIONALIDAD DE CREACIN

No siempre la creacin de objetos es sencilla, sobre todo cuando el sistema tiene muchos objetos. Es bueno crear un mecanismo lgico que permita abstraer toda la complejidad que existe en un sistema sofisticado para la creacin de mencionados objetos
20.2. PATRONES CON FUNCIONALIDAD ESTRUCTURAL
20.3. PATRONES CON FUNCIONALIDAD DE COMPORTAMIENTO
21. EXPLICACION DETALLADA DE LOS PATRONES

21.1. EJEMPLO PRCTICO DE APLICACIN DE FACTORY
Lo importante al aplicar el patrn Factory es que existan varias clases hijas(i) que hereden de una gran clase padre, de tal suerte que por medio de otra clase Factoria se
pueda invocar un mtodo de la misma con el nimo que sta sea capaz de entregar un objeto especfico hijo(i) que no siempre ser el mismo, pero que lo nico cierto es que siempre va a ser un objeto de una clase que a su vez hereda de la gran clase padre. En el caso particular que nos proponemos realizar tenemos la siguiente situacin: Se requiere hacer una clase que sea capaz de premiar a una carrera de la Universidad, dndole un cupo adicional a un estudiante para que ingrese a un proyecto curricular especfico. El proyecto curricular especfico que gana la premiacin se elige a la zar. Lo importante es que el programa sea capaz de crear verdaderamente el estudiante y que no sea fijo que se cree dicho estudiante. El programa propuesto anteriormente se puede resolver
Est_musica Est_preescolar Premiacion dev_Nuevo_Cupo : Estudiante
Estudiante
Est_sis_datos
Est_ing_civil
Est_electronica
Est_literatura
Ahora bien, para lograr una mayor comprensin del patrn, a continuacin se muestra el programa completo que implementa mencionado patrn y que trabaja las clases mostradas en el diagrama anterior:
import java.awt.*; import java.awt.event.*; public class MyApp extends Frame { public class Estudiante{ protected int cod_carrera; public int dev_Cod_carrera(){ return cod_carrera; } } public class Est_sist_datos extends Estudiante{ public Est_sist_datos(){ cod_carrera=1; System.out.println("Se ha creado un estudiante"); System.out.println("tipo Est_sist_datos");
public class Est_ing_civil extends Estudiante{ public Est_ing_civil(){ cod_carrera=2; System.out.println("Se ha creado un estudiante"); System.out.println("tipo Est_ing_civil"); } } public class Est_electronica extends Estudiante{ public Est_electronica(){ cod_carrera=3; System.out.println("Se ha creado un estudiante"); System.out.println("tipo Est_electronica"); } } public class Est_literatura extends Estudiante{ public Est_literatura(){ cod_carrera=4; System.out.println("Se ha creado un estudiante"); System.out.println("tipo Est_literatura"); } } public class Est_musica extends Estudiante{ public Est_musica(){ cod_carrera=5; System.out.println("Se ha creado un estudiante"); System.out.println("tipo Est_musica"); } } public class Est_preescolar extends Estudiante{ public Est_preescolar(){ cod_carrera=6; System.out.println("Se ha creado un estudiante"); System.out.println("tipo Est_preescolar"); } } public class Premiacion{ int sorteo; public Premiacion(){ sorteo = (int)(Math.random()*6); } public Estudiante dev_NuevoCupo(){ switch(sorteo){ case 0: return new Est_sist_datos(); case 1: return new Est_ing_civil(); case 2: return new Est_electronica();
case 3: return new Est_literatura(); case 4: return new Est_musica(); default : return new Est_preescolar(); } } // Cierra public Estudiante dev_NuevoCupo() } public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); Premiacion premiacion1 = new Premiacion(); Estudiante estudiante1 = premiacion1.dev_NuevoCupo(); int carrera = estudiante1.dev_Cod_carrera(); System.out.println("Se ha creado un nuevo"); System.out.println("cupo para un estudiante que"); System.out.println("pertenece a la carrera con"); System.out.println("codigo = "+carrera); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show(); } }
Los resultados del anterior programa son similares a los siguientes: Se ha creado un estudiante tipo Est_ing_civil Se ha creado un nuevo cupo para un estudiante que pertenece a la carrera con codigo = 2 Lo cual comprueba que verdaderamente se crea el cupo para un estudiante de ingeniera civil. Obviamente la ejecucin del anterior programa generara resultados diferentes cada vez que se ejecute, por ejemplo cuando el autor ejecut por segunda vez el anterior programa, se tuvieron los resultados siguientes: Se ha creado un estudiante tipo Est_electronica Se ha creado un nuevo
cupo para un estudiante que pertenece a la carrera con codigo = 3 Normalmente las clases que heredan las clases Factory heredan un comportamiento comn de una clase abstracta, pero implementan a su manera los mtodos abstractos.
21.2. EJEMPLO MAS ELABORADO USANDO FACTORY

El patrn Factory se presta para solucionar el siguiente problema: Se tienen diversos tipos de Estudiantes, realmente se tienen Estudiantes Excelentes, Estudiantes Buenos y Estudiantes Malos en donde todos ellos son capaces de presentar Evaluaciones y posteriormente entregarlas. Al momento de presentar la evaluacin pueden pasar cosas inesperadas, es decir un estudiante bueno puede presentar y entregar evaluaciones Excelentes, Buenas o Malas, esto debido a que las evaluaciones no solo dependen de los conocimientos, sino de la suerte que se tenga al escoger las respuestas o del estado anmico del estudiante en el momento de presentar esta evaluacin, por eso a nivel de software podemos pensar que la presentacin de la evaluacin es algo aleatorio. De otra parte existe la entidad Universidad y concretamente una instancia de una Universidad llamada Universidad Distrital en la cual se matriculan estudiantes, pero como todo proceso de matricula, es posible que lleguen estudiantes Malos, pero con notas buenas e ICFES bueno, y por esta razn sean recibidos en la Institucin, por eso podemos afirmar que este tipo de cosas para el caso del ejercicio que proponemos se puede tratar como un proceso de admisin aleatorio. El sistema debe brindar la posibilidad de imprimir un listado de los estudiantes Matriculados. Finalmente la Universidad hace un proceso al finalizar cada semestre en el que entrega menciones a los mejores estudiantes, en nuestro caso particular entregaremos menciones al estudiante que sea un estudiante Excelente por su trayectoria sin importar como le halla ido en el ultimo parcial. Para nuestro caso nos bastara con que el estudiante sea del tipo Estudiante Excelente para que le entregue la mencin. Obviamente el ejercicio anterior es un ejercicio un poco forzado ya que las Universidades de pronto no funcionen as, pero es simplemente para explicar como el uso del patron Factory se puede hacer no solamente en una clase, sino que al ser implementado en varias clases Factory ayuda a disminuir la dificultad a nivel de programacin para manejar la creacin de instancias de varias clases que en ultimas heredan funcionalidades de una superclase. Una solucin a nivel de programacin con el lenguaje Java propuesta es la siguiente:
import java.awt.*; import java.awt.event.*; import java.util.*;
public class MyApp extends Frame { public abstract class Parcial{ public String TipoParcial; public abstract String entregarTipoParcial(); } // Cierra class Parcial public class ParcialBueno extends Parcial{ public String entregarTipoParcial(){ return TipoParcial; } public ParcialBueno(){ TipoParcial = "BUENO"; } } // Cierra class ParcialBueno public class ParcialMalo extends Parcial{ public String entregarTipoParcial(){ return TipoParcial; } public ParcialMalo(){ TipoParcial = "MALO"; } } // Cierra class ParcialMalo public class ParcialExcelente extends Parcial{ public String entregarTipoParcial(){ return TipoParcial; } public ParcialExcelente(){ TipoParcial = "EXCELENTE"; } } // Cierra class ParcialExcelente public abstract class Estudiante{ int TipoExamen; public void presentarEvaluacion(){ TipoExamen = (int)(Math.random()*6); } public Parcial entregarEvaluacion(){ switch(TipoExamen){ case 2: return new ParcialExcelente(); case 1: return new ParcialBueno(); default: return new ParcialMalo(); } // Cierra switch } // Cierra entregarEvaluacion() } // Cieraa class Estudiante public class EstudianteExcelente extends Estudiante{ } public class EstudianteBueno extends Estudiante{
} public class EstudianteMalo extends Estudiante{ } public class Universidad{ Vector Matriculados = new Vector(); public void matricularEstudiantes(){ for(int i=0;i<10;i++){ int TipoEst = (int)(Math.random()*4); switch(TipoEst){ case 2 : Matriculados.addElement(new EstudianteExcelente()); case 1 : Matriculados.addElement(new EstudianteBueno()); default : Matriculados.addElement(new EstudianteMalo()); } } // Cierra for } // Cierra void matricular public void imprimirEstudiantesMatriculados(){ System.out.println(Matriculados.toString()); } public void entregarMencion(){ for(int i=0;i<10;i++){ Estudiante estu = (Estudiante)Matriculados.elementAt(i); if(estu instanceof EstudianteExcelente){ System.out.println("entrega mencion a estudiante"); } // Cierra if } // Cierra for } // Cierra void entregarMencion } // Cierra class Universidad public MyApp() { this.addWindowListener (new WindowAdapter(){ public void windowClosing(WindowEvent e){ dispose(); System.exit(0); } }); Universidad UDistrital = new Universidad(); UDistrital.matricularEstudiantes(); UDistrital.imprimirEstudiantesMatriculados(); UDistrital.entregarMencion(); } public static void main(String args[]) { System.out.println("Starting App"); MyApp f = new MyApp(); f.setSize(100,100); f.show();
Obsrvese que en la medida de lo posible es mejor procurar que la clase Estudiante sea una clase abstracta, que describa en lo posible en forma general las funcionalidades, pero que se implementen de diferente manera en las clases que hereden de dicha clase.
22. PATRON DE CREACION SINGLETON
22.1. PARTE TEORICA DEL PATRON SINGLETON

El patrn singleton lo que busca es poder crear una y como mximo una instancia de un objeto. Esto puede ser til cuando de usar recursos compartidos se trate. Por ejemplo en el uso de la impresora podemos decir que una vez esta siendo usada por una aplicacin no se debe permitir que otro usuario corte el trabajo del primero y comience a imprimir su trabajo. Para garantizar el xito del patrn singleton hacemos uso de una variable esttica al interior de la clase que queremos no tenga mas de una instancia. En nuestro caso queremos que la clase Impresora no tenga mas de una instancia y lo que se hace es preguntar por esta variable esttica en un mtodo cualquiera, casi siempre le llaman getInstance(), pero puede llamarse con cualquier nombre, lo importante es que en este mtodo si la variable es nula se permite la creacin del objeto y se le asigna un valor a dicha variable, pero si no lo es quiere decir que la variable no es nula y por lo tanto ya existe una instancia de esta clase, en nuestro caso una instancia de la clase Impresora, con lo cual el mtodo retorna nulo y esto hace que no se pueda crear otra instancia. A nivel de UML podemos decir que el diagrama de clases para el problema planteado es como sigue a continuacin:
Impresora static String trabajo Impresora getInstance()
En el ejercicio que nos proponemos desarrollar en la siguiente seccin queremos usar la anterior clase desde un programa llamado MyApp y esto en trminos de UML seria como se muestra a continuacin:
Impresora static String trabajo Impresora getInstance()
MyApp static void main()
Con lo anterior estamos diciendo con el rombo en la flecha que se trata de una agregacin y esto quiere decir que el programa MyApp puede existir si existen o no existen objetos tipo Impresora. Se le coloca una relacin unidireccional debido a que no es posible que una impresora contenga objetos de tipo MyApp. Y para especificar que tenemos o que estamos usando el patrn singleton, a continuacin le colocamos una multiplicidad a la relacin de asociacin tal como se muestra a continuacin:
Impresora static String trabajo Impresora getInstance() 0..1
MyApp static void main()
22.2. PARTE PRACTICA DEL PATRON SINGLETON

El planteamiento del problema de la seccin anterior se puede especificar en cdigo de la forma como se muestra a continuacin: Archivo MyApp.java
import java.awt.*; import java.awt.event.*; public class MyApp { public MyApp() { try{ Impresora epson1=null; for(int i=0;i<10;i++){ epson1 = Impresora.getInstance("trabajo "+i); if(epson1!=null){ System.out.println("epson1 se pudo crear"); } else{ System.out.println("epson1 no se pudo crear"); } } // Cierra for externo System.out.println(epson1.trabajo); } // Cierra try
catch(Exception e){ } } // Cierra MyApp public static void main(String args[]) { MyApp f = new MyApp(); }
Archivo Impresora.java
public class Impresora{ static String trabajo = null; public Impresora(String traba){ } public static Impresora getInstance(String trabajo1){ if(trabajo == null){ trabajo = trabajo1; return new Impresora(trabajo1); } else{ return null; } } // Cierra getInstance } // Cierra class PrimerAmor
22.3. OBSERVACIONES AL EJERCICIO DE SINGLETON

Observe amigo lector / estudiante que el cdigo de la seccin anterior exige que siempre se cree el objeto usando el mtodo getInstance, es decir ejecutando sentencias de la forma:
epson1 = Impresora.getInstance("trabajo "+i);
En otras palabras estamos diciendo que aunque a nivel de programacin se pueden crear los objetos con instrucciones como la siguiente:
Impresora impresora1 = new Impresora("Trabajin1");
Si usted quiere trabajar con el patrn singleton debe usar tan solo el mtodo getInstance() para la creacin de objetos porque si no se corre el riesgo que se este intentando crear un objeto que no sea el primero y el constructor no realizara este tipo de comprobaciones.
Otra de las cosas a tener en cuenta con el uso del patrn singleton es que la asignacin de un valor para la variable esttica usada como punto de referencia para controlar si ya se han creado instancias puede hacerse no necesariamente desde el mtodo getInstance(), es decir que para el ejercicio que venimos realizando podemos hacer la asignacin desde el mismo constructor de la clase, tal como se muestra a continuacin:
23. SOBRE LA CALIDAD DEL SOFTWARE
23.1. MODELOS DE CALIDAD

En la siguiente tabla se muestran los modelos mas conocidos sobre calidad: MODELO CARACTERISTICAS SPICE Se utiliza para la mejora de procesos y determinaci n de la capacidad. Incluye un proceso de medicin. Abarca todos los procesos relacionados con el desarrollo del software Nos dicen que debemos hacer Medio para evaluar que tan bien o mal esta la organizacin Abarca todos los Alinear las actividades de VENTAJAS Combina la experiencia y conocimien to aportado por CMM, Trilliumy Bootstrape ntre otros. AREAS DE NORMAS APLICACIN QUE APLICAN
CMM
CMMI
procesos relacionados con el desarrollo del software Se deben usar como referencia para definir procesos en una organizacin y para autoevaluaci n Evolucin de CMM con el objetivo de facilitar la integracin de varios modelos de forma simultnea. Incorpora un rea de proceso dedicada a Medicin y Anlisispa ra dar soporte al resto de reas de proceso. El estado de madurez se divide en 6 niveles (incompleto, ejecutado, gestionado, definido, cuantitativa mente
anlisis de la medicin Establecer los objetivos de la medicin. Especificar medidas. Especificar procedimie ntos de recogida y almacenam iento. Especificar procedimie ntos de anlisis. Proporcionarlos resultados de la medicin. Recoger los datos de la medicin. Analizar los datos de la medicin Almacenar los datos y resultados Comunicar los resultados
gestionado y optimizado). PSP Enfocado en individuos Enfocados a la ingeniera de productos de software Nos dice el cmo debemos hacer las cosas Se usa como gua para ejecutar proyectos Se basa en la mejora de los procesos, pero centrndose en el ingeniero de software. Proyectos cortos y de poca calidad. TSP Enfocados en equipos Diseado con el objetivo de Se trata de un proceso software diseado para mejorar las actividades y la productivid ad de los ingenieros. La calidad depende del trabajo de los ingenieros de software. Mejora la planeacin del trabajo. Mejora tcnicas de desarrollo.
(incluye psp) Enfocados a la ingenieria del software Proporciona los fundamento s necesarios para construir y guiar a un grupo de ingenieros software, que primero deben saber controlar su trabajo, y despus saber trabajar en equipo.
facilitar alcanzar el nivel 5 CMM. Contribuye a la administrac in eficiente de proyectos. Enfocados en reducir riesgos e incertidum bre en un proyecto de software.
TICKLT
Utiliza estrategias para lograr la certificacin en productos software
ISO-9001 ISO-90003
22.2. MODELO SPICE

Una norma que especifica el modelo SPICE es: Norma UNE 66-001-92 traduccin de ISO 8402
23.3. NORMA ISO 9000-2000

Es una norma internacional destinada a evaluar la capacidad de la organizacin para cumplir los requisitos del cliente, los reglamentarios y los propios de la organizacin. Ventajas

Tiene un mecanismo de certificacin bien establecido. Est disponible y es conocida.
Desventajas

No es especfica para la industria de software. No es fcil de entender. No est definida como un conjunto de procesos.
No es fcil de aplicar.
23.4. NORMA ISO 90003

Esta norma internacional proporciona una gua a las organizaciones para la aplicacin de la ISO 9001:2000 para la adquisicin, suministro, desarrollo, instalacin y mantenimiento de SOFTWARE y servicios de soporte. - No cambia ni aade los requisitos de la ISO 9001:2000. - No est destinada para ser utilizada como criterio de evaluacin en el registro/certificacin del sistema de calidad.
23.5. NORMA ISO/IEC TR 15504

Define el modelo de referencia de procesos de software y de capacidades de procesos que constituyen la base para la evaluacin de procesos de software. Se compone de 9 partes de las cuales la 2, 3 y 9 son normativas y las dems informativas. Ventajas

Especfico para el desarrollo y mantenimiento de software. Fcil de entender (24 procesos, 16 pginas). Definido como un conjunto de procesos. Orientado a mejorar los procesos para contribuir a los objetivos del negocio.
Desventajas

No es prctico ni fcil de aplicar. Tiene solamente lineamientos para un mecanismo de evaluacin. Todava no es norma internacional.
Proporciona un marco de trabajo para la evaluacin del proceso y establece los requisitos mnimos para realizar una evaluacin que asegure la repetibilidad y consistencia de las valoraciones obtenidas El objetivo de la evaluacin del proceso es conocer la capacidad de los procesos de una organizacin. Como resultado de una exitosa implementacin de la evaluacin de los procesos se determina la informacin que caracteriza los procesos evaluados y el punto hasta el cual los procesos realizan su propsito
23.6. ESTANDAR ISO 9126

El estndar ISO 9126 define 6 atributos de calidad del software que son la funcionalidad, la confiabilidad, la facilidad de uso, la eficiencia, la facilidad de mantenimiento y la portabilidad, a continuacin se explican en detalle cada uno de ellos: Funcionalidad: El grado en el que un sistema satisfacen las necesidades que indican los siguientes subatributos: idoneidad, exactitud, interoperabilidad, cumplimiento y seguridad. Confiabilidad: La cantidad de tiempo en que el software esta disponible para usarlo segn los siguientes atributos: madurez, tolerancia a fallas y facilidad de recuperacin. Facilidad de uso: La facilidad con que se usa el software de acuerdo con los siguientes subatributos: facilidad de comprensin, facilidad de aprendizaje y operabilidad. Eficiencia: El grado en que el software emplea en forma optima los recursos del sistema, como lo indican los siguientes subatributos: comportamiento en el tiempo, comportamiento de los recursos. Facilidad de mantenimiento: La facilidad con que se repara el software de acuerdo con los siguientes subatributos, facilidad de anlisis, facilidad de cambio, estabilidad y facilidad de prueba. Portabilidad: La facilidad con que se lleva un software de un entorno a otro segn los siguientes atributos: adaptabilidad, facilidad para instalarse, cumplimiento, facilidad para reemplazarse.
Y aunque los anteriores atributos no se pueden medir directamente son una base para realizar medidas indirectas.
23.7. MODELOS CMMI

Los 6 niveles definidos en CMMI para medir la capacidad de los procesos son: 0. Incompleto: El proceso no se realiza, o no se consiguen sus objetivos. 1. Ejecutado: El proceso se ejecuta y se logra su objetivo. 2. Gestionado: Adems de ejecutarse, el proceso se planifica, se revisa y se evala para comprobar que cumple los requisitos. 3. Definido: Adems de ser un proceso gestionado se ajusta a la poltica de procesos que existe en la organizacin, alineada con las directivas de la empresa. 4. Cuantitativamente gestionado: Adems de ser un proceso definido se controla utilizando tcnicas cuantitativas. 5. Optimizado: Adems de ser un proceso cuantitativamente gestionado, de forma sistemtica se revisa y modifica o cambia para adaptarlo a los objetivos del negocio. Conocimientos incluidos y disponibles en CMMI Systems engineering (SE) Software engineering (SW) Integrated product and process development (IPPD) Supplier sourcing (SS) Su contenido integra y da relevo a la evolucin de sus predecesores: CMM-SW (CMM for Software) SE-CMM (Systems Engineering Capability Maturity Model) IPD-CMM (Integrated Product Development) VENTAJAS REPRESENTACIN POR ETAPAS Su contenido integra y da relevo a la evolucin de sus predecesores: CMM-SW (CMM for Software) SE-CMM (Systems Engineering Capability Maturity Model) IPD-CMM (Integrated Product Development) REPRESENTACION CONTINUA Su contenido integra y da relevo a la evolucin de sus predecesores: CMM-SW (CMM for Software) SE-CMM (Systems Engineering Capability Maturity Model) IPD-CMM (Integrated Product Development) AREAS DE APLICACIN rea de proceso Anlisis y resolucin de problemas Categora Soporte Nivel de madurez 5
Gestin de la configuracin Anlisis y resolucin de decisiones Gestin integral de proyecto Gestin integral de proveedores Gestin de equipos Medicin y anlisis Entorno organizativo para integracin Innovacin y desarrollo Definicin de procesos Procesos orientados a la organizacin
Soporte Soporte Gestin de proyectos Gestin de proyectos Gestin de proyectos Soporte Soporte Gestin de procesos Gestin de procesos Gestin de procesos
2 3 3 3 3 2 3 5 3 3 4 3 3 2 2 2 4 3 2 3 2 3
Rendimiento de los procesos de la org. Gestin de procesos Formacin Integracin de producto Monitorizacin y control de proyecto Planificacin de proyecto Gestin calidad procesos y productos Gestin cuantitativa de proyectos Desarrollo de requisitos Gestin de requisitos Gestin de riesgos Gestin y acuerdo con proveedores Solucin tcnica Gestin de procesos Ingeniera Gestin de proyectos Gestin de proyectos Soporte Gestin de proyectos Ingeniera Ingeniera Gestin de proyectos Gestin de proyectos Ingeniera
Validacin Verificacin
Ingeniera Ingeniera
3 3
23.8. TALLER PROPUESTO DE CALIDAD

1. Averiguar los factores de calidad de McCall. 2. Realizar un ejemplo de un programa sencillo y de forma creativa intentar medir la funcionalidad, la confiabilidad, la facilidad de uso, la eficiencia, la facilidad de mantenimiento y la portabilidad. 3. Investigar segn el estndar ISO 9126 que significa: idoneidad, exactitud, interoperabilidad, cumplimiento y seguridad. 4. Investigar segn el estndar ISO 9126 que significa: madurez, tolerancia a fallas y facilidad de recuperacin. 5. Investigar segn el estndar ISO 9126 que significa: facilidad de comprensin, facilidad de aprendizaje y operabilidad. 6. Investigar segn el estndar ISO 9126 que significa: comportamiento en el tiempo, comportamiento de los recursos. 7. Investigar segn el estndar ISO 9126 que significa: facilidad de anlisis, facilidad de cambio, estabilidad y facilidad de prueba. 8. Investigar segn el estndar ISO 9126 que significa: adaptabilidad, facilidad para instalarse, cumplimiento, facilidad para reemplazarse. Es posible que algunos trminos no estn definidos en la norma, en cuyo caso debe realizarse una investigacin en otras fuentes sobre dichos atributos con el fin de dar una definicin completa del mencionado y para cada todos los atributos que no tengan su definicin en la norma.
24. LOS SISTEMAS DE CONTROL DE VERSIONES

El siguiente trabajo pretende mostrar los avances en cuanto a los sistemas de control de versiones que son da por da uno de los temas ms apasionantes dentro del enorme campo de la Ingeniera de Software, tambin se pretende dar unas pautas sobre las caractersticas globales de los CVS, adems de analizar con algo de detalle las perspectivas a futuro que se tienen para con los CVS. Es importante notar que el presente artculo trata en lo mximo de hacer algunas comparaciones entre los sistemas amparados bajo licencia GNU y algunos propietarios para mostrar algunas de las caractersticas que ofrecen ellos para implementar sistemas de control de versiones.
24.1. LOS CVS Y EL PROCESO DE DESARROLLO UNIFICADO

El proceso unificado de desarrollo est compuesto por fases e iteraciones. Una fase es un intervalo de tiempo entres dos hitos importantes del proceso durante la cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman las decisiones sobre si pasar a la siguiente fase. Las cuatro fases del proceso unificado son: Iteracin Elaboracin Construccin Transicin Dentro de cada fase hay varias iteraciones que algunos denominan flujos de trabajo y que son: Modelo del negocio: Describe la estructura y la dinmica de la organizacin Requisitos: Describe el mtodo basado en casos de uso para extraer los requisitos Anlisis y Diseo: Describe las diferentes vistas arquitectnicas Pruebas: Describe los casos de pruebas, los procedimientos y mtricas para evaluacin de defectos. Gestin de Configuraciones: Controla los cambios y mantiene la integridad de los artefactos de un proyecto Gestin del Proyecto: Describe varias estrategias de trabajo en un proceso iterativo Entorno. Cubre la infraestructura necesaria para desarrollar un sistema
Dentro del marco terico plasmado anteriormente vemos que la gestin de configuraciones cobra una especial importancia en el desarrollo de sistemas y obviamente como casi todas las cosas han sido plasmadas primero en forma terica por expertos del rea y luego algunas personas han tratado de dar soluciones reales en el rea. Pues bien, la gestin de configuraciones es un rea tratada durante aos por la Ingeniera de Software, pero en los ltimos aos se ha incrementado su inters tanto que surgieron teoras al respecto. La cuestin es que dentro de la gestin de configuraciones un punto bien importante a tratar es
la gestin de versiones cosa que hasta hace unos aos se trataba solamente en forma terica, pero afortunadamente en estos ltimos cinco aos se ha visto favorecida debido al surgimiento de sistemas que permiten a los desarrolladores de sistemas gestionar las versiones e incluso ir ms all y gestionar las subversiones. Obviamente los sistemas actuales que permiten la gestin de configuraciones son sistemas que tienen algunas limitaciones, pero que as mismo tambin brindan algunas facilidades y ste es precisamente el objetivo de este artculo, poder dar una idea mundial del estado en el que se encuentran dichos sistemas y poder hacer algunas predicciones de los posibles caminos que pueden tomar estos sistemas basndonos en las cuestiones que les hace falta mejorar a los sistemas actuales. Tambin se pretenden sacar algunas conclusiones sobre lo que son y lo que no son los sistemas de gestin de configuraciones. Se han realizado algunos trabajos sobre el tema, pero han sido desarrollados en su mayora por personas que estn inclinadas tecnolgicamente a utilizar una u otra tecnologa, por ejemplo Microsoft ha publicado algunos trabajos para hablar sobre la gestin de configuraciones y especficamente sobre la gestin del control de versiones en proyectos de desarrollo de sistemas, pero inmediatamente despus comienza hablando sobre las herramientas que ofrece para apoyar dicha gestin, esto obviamente se hace debido a que estn inclinados por la utilizacin de dichas herramientas. En otros casos algunos fervientes amantes del software amparado por GNU muestran a los sistemas CVS de cdigo abierto como los mejores, pero la verdad es bueno tener el objetivismos para hacer anlisis medios en los que no se subestime una u otra tecnologa. En este sentido el presente artculo espera ser de valiosa ayuda para todo aquel que quiera comprender el estado actual de los sistemas de control de versiones.
24.2. LA GESTION DE CONFIGURACIONES Y LOS CVS

El tema de la gestin de configuraciones y especficamente la gestin de control de versiones tiene un ingrediente tecnolgico que puede tratarse ms o menos de forma objetiva, pero tambin tiene un ingrediente social, por cuanto surge como una necesidad inicialmente plasmada por la Ingeniera de Software y en este sentido se tiene mucha subjetividad, debido a que la Ingeniera de Software tiene muchos paradigmas y metodologas y dependiendo de la que se utilice se ve el desarrollo de sistemas de una u otra forma. Este trabajo por tanto aunque intenta ser lo ms objetivo no garantiza en un ciento por ciento que sea una fiel copia de lo que es la realidad en el tema de la gestin de versiones de sistemas, pero a pesar de serlo intenta ser lo ms cercano a lo que realmente se est viendo en las organizaciones sobre el tema.
24.2. CONTENIDO DE LA UNIDAD

En esta unidad se pretende abordar los siguientes objetivos: Dar varios puntos de vista sobre los que son los CVS (Sistemas de control de versiones)
Indagar sobre los tipos de sistemas de control de versiones Analizar el papel que cumplen los CVS dentro de la Ingeniera de Software Indagar sobre los desarrollos ms importantes actualmente hechos por empresas desarrolladores de sistemas para ayudar a implementar CVS Observar las caractersticas que deben tener los buenos CVS y hacer algunas precisiones sobre el futuro que tienen estos sistemas en el desarrollo de sistemas a largo y mediano plazo. Precisas algunas conclusiones que no se encuentren en textos algunos, sino que sean el resultado de analizar lo que son los CVS y de su estado actual.
24.3. CONCRETANDO LO QUE ES UN CVS

Como hemos visto hasta el momento los CVS son de gran importancia en la actualidad y es un soporte valioso que tiene ahora la Ingeniera de Software para seguir fundamentando teoras que muestran a estos sistemas como sistemas estratgicos e importantes para cualquier empresa que desarrollo sistemas. Comenzaremos dando una definicin de los que se entiende por CVS y luego haremos un estudio detallado de los tipos y caractersticas de CVS, para concluir con unas prospectivas hacia el futuro y con unas conclusiones sobre los CVS. Definicin: CVS es bsicamente un sistema de control de versiones [Ref 1, I] y actualmente podemos decir que es uno de los temas de gran inters para la Ingeniera de Software, debido bsicamente a que si es manejado adecuadamente dicho control permitir a los desarrolladores llevar un control estricto de sus versiones y poder volver con total seguridad a una de ellas cuando se presenten problemas posteriores en el desarrollo del sistema. La tcnica ms comn para la implantacin de un sistema de versiones es trabajar en directorios de trabajo y solo personas con permisos especiales pueden hacer envos a dichos repositorios [Ref 2].
24.4. TIPOS DE SISTEMAS DE CONTROL DE VERSIONES

Lo ms comn en grandes empresas desarrolladoras de sistemas es que se cuente con un servidor dedicado nicamente al manejo de las versiones y dicho servidor maneja el repositorio antes mencionado. La administracin de mencionado servidor se debe hacer por personal altamente calificado y debe ser configurado de acuerdo con el tipo de servidor de versiones que se quiera implementar. Por ejemplo podemos hablar de servidores de versiones concurrentes y servidores de versiones no concurrentes[Ref 2] y sin importar el tipo de servidor de versiones que se quiera montar se pueden establecer diferentes tipos de
No solamente un CSV es esto, sino que tiene otras cosas como poder sacar instantneas de cualquier momento de la historia a parte de manejar unas tecnologas complejas que son descritas con ms detalle en [Ref 1]
usuarios con respecto al servidor de versiones. Es as como encontramos usuarios administradores, usuarios annimos e invitados[Ref 2,II] Existen variedad de formas para implementar sistemas de control de versiones [Ref 3] [Ref 4] [Ref 5], entre los que tenemos: Sistema de control de versiones clsico Modelo optimista de control de modificaciones concurrentes Clientes disponibles para muchas plataformas Modelo cliente-servidor (no desde el principio) Gestin conjunta de grupos de ficheros Sistemas complementarios pueden soportar acceso va web
24.5. LOS CVS Y LA INGENIERA DE SOFTWARE

Para comprender el papel del control de versiones dentro de la Ingeniera de Software es bien importante comenzar por recordar que el objetivo principal de la Ingeniera de Software es entregar un producto que satisfaga las necesidades del usuario, de forma eficiente y predecible[Ref Bib 1, pag 399] y se podra pensar que este principio se ha mantenido vigente durante los ltimos quince aos, pues desde entonces la Ingeniera de Software siempre ha perseguido este fin. De otra parte es interesante notar que la ingeniera de software ha basado el logro de este ideal utilizando dos metodologas principales: La metodologa de proceso y la metodologa de desarrollo, en donde hoy por hoy se tiene bastante difundida la metodologa de proceso RUP, que traduce Proceso unificado de desarrolloIII, lo interesante del asunto es ver que sta metodologa no solamente es compatible con una metodologa de desarrollo, sino que lo es con muchas, lo que sucede es que los desarrolladores de stas metodologas recomiendan que se implemente sta metodologa de proceso con una metodologa de desarrollo orientada a objetos, y bueno, dado que las metodologas orientadas a objetos modernas usan a UML como su lenguaje base, no es raro comprender que incluso se documente el proceso con UML. [Ref Bib 3, pag 25]. En este punto es importante aclarar que el proceso de desarrollo unificado es ms que una metodologa de desarrollo y como lo describen algunos autores: Soporta las tcnicas orientadas a objetos [Ref Bib 1, pag 400]. Pues bien, el proceso unificado de desarrollo tiene unas fases que son: Iniciacin Elaboracin Construccin Transicin
II
En esta referencia encuentra tambin como configurar estos permisos para los diversos usuarios del servidor de control de versiones. III Sobre este proceso podemos encontrar bastante informacin en el libro [Ref Biblio 2] denominado The Unified Software Development Process
y en cada una de estas fases se tienen unos flujos de trabajo del proceso que son: Modelado del negocio Requisitos anlisis y diseo implementacin Pruebas Despliegue Flujos de trabajo de soporte Gestin del Cambio y configuraciones Gestin del proyecto Entorno La pregunta que hasta ahora se ha hecho la Ingeniera de Software es: Cmo hacer una verdadera gestin del cambio y configuraciones?. Para responder a ste pregunta se han establecido una serie de pasos a nivel metodolgico y algunos de estos pasos se encuentran incluso dentro de metodologas como CMM cuando la incluyen en las primeras etapas para llevar a los equipos de desarrollo a niveles de calidad altos[Ref 12], pero lo interesante es que hasta hace muy poco se cuenta con herramientas computaciones que permitan el desarrollo de sta tarea en forma efectiva, es entonces cuando surge CSV como un sistema que se puede implementar para el control de versiones y por supuesto las grandes empresas de software han ahondado en esfuerzos tendientes a dar soluciones al problema del control de versiones e incluso como se ver ms adelante algunas no solamente se quedan en el problema de las versiones, sino que quieren detallar ms el proceso y piensan en el problema de las subversiones.
24.6. SISTEMAS PARA GESTIONAR LOS CVS

Existen muchos desarrollos tendientes a dar soluciones a implementaciones reales de CVS, uno de ellos es aegis[Ref 6], el cual pone especial nfasis en la seguridad del almacn y es por hoy una buena solucin debido a que permite un acceso web a los administradores y usuarios del sistema. Este sistema podramos decir que implementa la idea de modelos de proyectos (proyect templates) que no son ms que plantillas sobre las que se consigna informacin sobre los diversos proyectos que son administrados por el CVS[IV] Existe un sistema que ha sido desarrollado para manejar versiones y subversiones y que ha tenido gran aceptacin en el mundo y es arch[Ref 7], el cual tiene muchas posibilidades de distribucin y es bastante ligero, incluso hay quienes lo consideran el mejor sistema para
IV
Es importante notar que personas como el Dr Jess M. Gonzlez Barahona profesor de la Universidad de Juan Rey en Espaa dicen que aegis tiene una funcionalidad similar a los CVS. Al doctor lo podemos encontrar en la direccin eletrnica: jgb@computer.org jgb@gsyc.escet.urjc.es
el manejo de versiones. De todas formas lo nico cierto es que ha tenido gran aceptacin mundial y un crecimiento grande del nmero de empresas y entidades que lo implementan. Existe un sistema llamado Vesta[Ref 8], el cual permite el control de versiones y adicionalmente est concebido con nfasis en el rendimiento y ha sido pensado para grandes sistemas, lo malo es que hasta el momento ha sido difcil de portar, por cuanto actualmente funciona solamente sobre LINUX. Para el caso de Microsoft tenemos que esta gran empresa de desarrollo de soluciones informticas ha pensado en dar soluciones especficas para desarrolladores pequeos y para desarrolladores grandes. Para las empresas de desarrollo pequeas y/o desarrolladores independientes la solucin es Visual Source Safe 2005 y para desarrollos complejos la solucin est basada en Visual Studio 2005 Team System: Enterprise Class Source Control and work Item Tracking[Ref 9]. Entre las cosas ms atractivas de las soluciones ofrecidas por Microsoft, podemos citar el hecho que dichas herramientas ofrecidas por esta empresa para el control de versiones cubren aspectos como el modelado, la documentacin, las pruebas, la administracin del software y en s se podra decir que son herramientas que satisfacen las necesidades completas para la administracin del ciclo de vida del software.
24.7. OTROS SISTEMAS QUE APOYAN A LOS CVS

Algunos desarrollos de software han hecho que los CVS indirectamente cojan fuerza y sean da por da una realidad en la ingeniera de software. Tenemos por ejemplo muchas herramientas tipo gnu[IV] que ayudan a definir y catalogar cadenas de texto que van a ser usadas por los programas[V], otros que ayudan a automatizar la gestin de cambios de idioma[Ref 10,VI]
24.8. CARACTERISTICAS QUE DEBE TENER UN BUEN CONTROL DE VERSIONES

Antes de mostrar algunas de las caractersticas ms importantes que debe tener un buen control de versiones, es necesario pensar en algunas cuestiones preliminares que ayuden a comprender el tema y la importancia del control de versiones. Veamos: Cuando se habla de control de versiones, se piensa inmediatamente en el cdigo fuente de las aplicaciones, pero es necesario comprender que el control de versiones no solamente debe abarcar ste aspecto sino que debe cubrir aspectos como los requisitos, los diagramas,
IV V
Si quiere saber ms sobre GNU puede entrar a la direccin electrnica: http://www.gnu.org Estos programas ayudan a catalogar programas y algunos autores lo denominan catlogo de mensajes
VI
Es importante notar que para automatizar la gestin de cambio de idioma se deben primero establecer reglas simples para especificar las traducciones que se deben hacer, tal como lo menciona el Dr Jess M. Gonzlez Barahona a quien le podemos escribir a la direccin: jgb@computer.org jgb@gsyc.escet.urjc.es
la documentacin. El establecer cuando se llega a una versin es algo importante y debe obedecer a polticas institucionales de desarrollo de versiones. Es importante pues en este sentido que no se establezcan versiones definitivas sin antes haber pasado dichos productos por otro tipo de versiones. En este sentido tenemos pues que un buen mecanismo para establecer versiones, es definir tipos de versiones como pueden ser: versiones alfa, versiones beta y versiones definitivas. Ahora bien, veamos entonces algunas de las caractersticas que debe tener un buen control de versiones: Un sistema de control de versiones debe primero que todo tener la posibilidad de darle al desarrollador la posibilidad de establecer el momento en el que desea indicarle al sistema que tiene una versin. Obviamente este momento tiene que estar acompaado de un almacenamiento confiable de toda la informacin del proyecto en el momento de tomar la decisin de establecer la fijacin de una versin. De otra parte podemos pensar que de la anterior caracterstica surge otra bien importante y que tiene que ver con la posibilidad que debe tener el desarrollador de sistemas de conocer cuales son las diferencias que se tienen entre lo que se tiene actualmente con la ltima versin, esto con el fin de saber si ya es el momento preciso para tener una nueva versin, o de si todava los esfuerzos hechos no ameritan el lanzamiento de una nueva versin. Los sistemas de control de versiones deben ser sistemas que soporten varios programadores trabajando al mismo tiempo, algo similar a lo que pasaba cuando comenzaron los primeros entornos de desarrollo para trabajar en aplicaciones web. Recordemos por ejemplo lo que hizo Microsoft con su herramienta inicial Microsoft Visual Interdev 6.0 en la que se trabajaban simultneamente los conceptos de servidor de produccin (que procesaba las pginas), servidor maestro (que procesaba las copias principales) y servidor local (que se encontraba en una estacin de trabajo y proporcionaba funcionalidades necesarias para probar todos los tipos de elementos web antes de extenderlos a la aplicacin web maestra) [Ref Bib 4, pag 476]. Pues bien en los sistemas de control de versiones se mejoran estos conceptos y se permiten seguridades ms grandes y controles no solamente a nivel de cdigo fuente, sino a nivel de auditora para saber en determinado momento que desarrollador hizo un cambio que da el desarrollo del sistema, para que sea almacenado por medio de registros recuperables que permitan con un gran alto grado de seguridad recuperar la versin con toda su funcionalidad. Los buenos sistemas de control de versiones deben permitir al equipo desarrollador recuperar versiones previas en el desarrollo del ciclo de vida del software que muestren no solamente las lneas que han cambiado, sino la documentacin que ha sido agregada y/o eliminada, entendiendo por documentacin los diagramas, los diccionarios, la documentacin del cdigo fuente, tal como por ejemplo lo implementa Visual Source Safe [Ref 13] Los sistemas de control de versiones deben tener capacidades de compartir y enlazar archivos de desarrollo para promover la reutilizacin de cdigo y componentes entre proyectos y simplificarel mantenimiento de cdigo al preparar los cambios entre todos los
archivos compartidos y enlazados cuando un archivo sea actualizado, lo cual por ejemplo es algo que tambin implementa Visual Source Save[Ref 13] Las caractersticas de desarrollo en parelelo, como el "branching", permite que los equipos separen el proceso de desarrollo en proyectos y archivos paralelos, creando copias idnticas que heredan toda la documentacin de versiones pero que se les puede dar seguimiento como proyectos nuevos e individuales[Ref 13]. Esto obviamente debe estar soportado por una alta tecnologa que permita reconciliar diferencias entre diferentes versiones del mismo archivo y permita ver como se comportara una determinada versin al ser incluida dentro del proyecto, pero todo esto bajo la premisa de evitar al mximo la prdida potencial de cambios valiosos. Al igual que con los usuarios de cualquier otro sistema, los sistemas de control de versiones deben permitir manejar niveles de usuarios aunque globalmente todos sean desarrolladores de software y de sistemas es bueno que el sistema de control de versiones permita la gestin de usuarios en el equipo de desarrollo basado en polticas de seguridad y niveles de permisos [Ref 3] [Ref 4].
24.9. EL FUTURO DE LOS CVS

Como sucede con casi todas las cosas del mundo, los desarrollos tecnolgicos tambin estn en constante cambio y evolucin, pues bien, los CVS que fueron concebidos para manejar versiones pueden llegar a ser desplazados por los sistemas que manejan subversiones, los cuales a parte de ser netamente web permiten gestionar directorios renombrados y tienen algoritmos bastante eficientes para hacer bsquedas y para gestionar subversiones[Ref 11].
24.10. CONCLUSIONES SOBRE LOS CVS

Es importante notar que los CVS han evolucionado a sistemas que permiten un alto grado de confiabilidad para la gestin de versiones en el ciclo de vida de sistemas y se enfoca principalmente en permitir el trabajo de mltiples usuarios que fsicamente se pueden encontrar en cualquier parte del mundo. Podemos decir entonces que aunque los CVS que existen actualmente funcionan preferencialmente en entornos LAN, tambin soportan WAN y tienden a soportar sta ltima de forma robusta cada vez ms. Se puede ver claramente que de todas formas existe algo de responsabilidad grande delegada al administrador del CVS, debido a que de los permisos que ste conceda a los usuarios y de la buena gestin que haga del sistema depender en buena medida el xito del manejo de versiones en un proyecto de desarrollo. Esto obviamente tiene una limitacin y es que el administrador de control de versiones debe ser una persona con alto grado de conocimientos de programacin y buena responsabilidad del control de versiones recae sobre el mismo.
Cuando surgen problemas en el desarrollo del sistema y se toma la decisin de volver a una versin previamente almacenada se puede fcilmente volver con las herramientas actuales, pero si por desgracia se quiere volver a un tiempo en el ciclo de desarrollo del sistema que no halla sido previamente almacenado y establecido en el sistema, se tienen actualmente muchas limitaciones en todos los sistemas CVS actuales. Tambin podemos decir que aunque los CVS actuales permiten combinar archivos diferentes que correspondan a versiones diferentes, existe todava un alto grado de posibilidad que al hacerlo un archivo pueda estropear indirectamente otras cosas, pero que no sea tan evidente. En estos casos, decimos que para reconciliar de una mejor manera los problemas al mezclar archivos se deben hacer simulaciones de cmo sera la integracin del sistema, pero dichas simulaciones todava no son posibles con los CVS actuales. Otra cuestin bien relacionada con la conclusin anterior es que al combinar diversas versiones se toman decisiones basadas en la experiencia, el buen conocimiento de programacin y otras cuestiones que de ninguna manera pueden ser reemplazadas por sistemas actuales. Decimos entonces que tcnicas como la inteligencia artificial todava no se han integrado de forma plena a los CVS actuales. Podemos pensar que los actuales CVS estn diseados para gestionar versiones de desarrollo de software en lenguajes especficos, por ejemplo los sistemas creados por Microsoft, son para ser utilizados en equipos de desarrollo que usen herramientas de Microsoft, de la misma forma otros sistemas en software amparado por GNU siguen siendo especficos para ciertos lenguajes de programacin y esto obviamente lleva a pensar que estamos muy lejos de construir sistemas de control de versiones que soporten desarrollos de sistemas basados en mltiples lenguajes.
24.11. BIBLIOGRAFIA DE LA UNIDAD

[Ref Bib 1] Nombre: Autor(es): Editorial: Ao: [Ref Bib 2] Nombre: Autor(es): Editorial: Ao: [Ref Bib 3] Nombre: Autor(es):
El Lengueje Unificado de Modelado Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley 1999 El Lengueje Unificado de Modelado Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley 2002 The Unified Software Development Process Grady Booch, James Rumbaugh, Ivar Jacobson
Editorial: Ao: [Ref Bib 4] Nombre: Autor(es): Editorial: Ao:
Addison Wesley Object Technology Series 2003 Microsoft Visual Interdev 6.0 Manual del programador Microsort Press Mc Graw Hill 1999
24.12. INFOGRAFIA DE LA UNIDAD

[Ref 1] Direccin: Copias: http://gsyc.escet.urjc.es/pub/actividades/linuxprog/prog-html.tar.gz http://gsyc.escet.urjc.es/pub/actividades/linuxprog/prog-dvi.tar.gz http://gsyc.escet.urjc.es/pub/actividades/linuxprog/prog.ps.gz Fecha: 31 de Mayo de 2001 [Ref 2] Direccin: http://qref.sourceforge.net/Debian/reference/reference.es.html#contents Fecha: 14 de Enero de 2005 [Ref 3] Direccin: http://www.cvshome.org Fecha: 30 de Octubre de 2003 [Ref 4] Direccin: http://www.gnu.org/software/cvs/cvs.html Fecha: 27 de septiembre de 2004 [Ref 5] Direccin: http://cvsbook.red-bean.com Fecha: 3 de Enero de 2005 [Ref 6] Direccin: http://aegis.sourceforge.net/index.html Fecha: 13 de Agosto de 2005 [Ref 7] Direccin: http://regexps.com/arch.html Fecha: 14 de enero de 2005 [Ref 8] Direccin: http://www.vestasys.org Fecha: 17 de diciembre de 2005 [Ref 9]
Direccin:
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnvsent/html/vsts-arch.asp Fecha: 5 de Febrero de 2005 [Ref 10] Direccin: http://www.gnu.org/software/gettext/gettext.html Fecha: 10 de septiembre de 2004 [Ref 11] Direccin: http://subversion.tigris.org Fecha: 17 de diciembre de 2005 [Ref 12] Direccin: http://www.acis.org.co/index.php?id=108 Fecha: 18 de octubre de 2005 [Ref 13] Direccin: http://www.microsoft.com/latam/ssafe/producto/resumen.asp Fecha: 29 de diciembre de 2004
25. BIBLIOGRAFIA
25.1. BIBLIOGRAFIA SOBRE PROCESOS DE DESARROLLO Y RUP

Ivar Jacobson, Grady Booch e James Rumbaugh. The Unified Software Development Process. Captulos 1 a 5. Philippe Kruchten. The Rational Unified Process an Introduction. Pressman Roger. Ingeniera del Software. Quinta edicin. Editorial Mc Graw Hill. 2002. Booch, G. Rumbaugh, J. Jacobson, I. El Proceso Unificado de Desarrollo de Software. Editorial Addison Wesley. 2000 Bruegge, Bern. Dutoit, Allen. Ingeniera de Software Orientada a Objetos. Editorial Prentice Hall. 2000. Fraude, Eric. Ingeniera de Software una perspectiva orientada a objetos. Editorial Alafaomega. 2003. Sommerville, Ian. Ingeniera de Software. Editorial Pearson Education. Sexta edicin. 2002. Amescua, Antonio. Cuadrado, Juan Jose. Ernica, Emilio. Garca, Javier. Garca, Luis. Martinez, Paloma. Anlisis y diseo estructurado y orientado a objetos de sistemas informticos. Editorial Mc Graw-Hill. 2003.
25.2. BIBLIOGRAFIA SOBRE MODELAMIENTO CON UML

Booch, G. Rumbaugh, J. Jacobson, I. El lenguaje unificado de modelado. Editorial Addison Wesley. 1999. Sintes, Anthony. Programacin Orientada a Objetos. Editorial Prentice Hall. 2002. Modelado y Diseno orientado a objetos. Metodologia OMT. James Rumbaught, Michael Blaha, William Premerlani, Frederick Eddy y William Lorensen. Editorial Prentice Hall. 1995. (Este libro no habla de UML, pero muchas de estas cosas las tomo UML)
25.3. BIBLIOGRAFIA SOBRE IMPLEMENTACIONES CON UML

Java y UML.

Rup Uml

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rup Uml

Diunggah oleh

Hak Cipta:

Format Tersedia

LIBRO PARA LA ASIGNATURA DE ANALISIS DE SISTEMAS

2.1. LAS FASES Y LOS FLUJOS DE RUP

Flujos de trabajo de proceso

Flujos de trabajo de soporte

Diagrama elaborado por Luis Felipe Wanumen Silva.

Flujos de trabajo de proceso

Flujos de trabajo de soporte

Flujos de trabajo de soporte relevantes para documentar

Flujos de trabajo de soporte NO relevantes para documentar

Dan calidad a los flujos de proceso

Flujos de trabajo de proceso

Flujos de trabajo de soporte

Flujos de trabajo de soporte relevantes para documentar

Flujos de trabajo de soporte NO relevantes para documentar

LOS FLUJOS DE TRABAJO EN RUP

Elaboracin Construccin FASES DE RUP Transicin

2.2. FASE DE INICIACION EN RUP

FASE . FASE DE INICIACION 22%

FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO

ANALISIS Y DISEO IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO ADMINISTRACION

1,00% 1,00% 0,00% 0,00% 2,00% 2,00%

2.3. FASE DE ELABORACION EN RUP

IMPLEMENTACION TEST PRUEBAS DESPLIEGUE

2,00% 1,00% 1,00%

CONFIGURACION Y MANTENIMIENTO ADMINISTRACION

Que es muy coherente con lo expuesto en el diagrama inicial de RUP:

2.4. FASE DE CONSTRUCCION EN RUP

Podramos proponer el siguiente cronograma para la fase de construccin de un sistema de informacin:

IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO

10,00% 2,00% 1,00% 5,00%

2.5. FLUJO DE TRANSICION EN RUP

CRONOGRAMA BASADO EN RUP PLANTILLA FLUJOS DE TRABAJO

FASE DE INICIACION 22%

REQUERIMIENTOS ANALISIS Y DISEO IMPLEMENTACION TEST PRUEBAS DESPLIEGUE CONFIGURACION Y MANTENIMIENTO

FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO REQUERIMIENTOS

FASE DE CONSTRUCCION 30%

IMPLEMENTACION TEST PRUEBAS DESPLIEGUE

CONFIGURACION Y MANTENIMIENTO ADMINISTRACION AMBIENTE

FLUJOS DE TRABAJO NEGOCIOS Y MODELAMIENTO REQUERIMIENTOS ANALISIS Y DISEO

FASE DE TRANSICION 26%

2. CONSIDERACIONES AL REALIZAR SU PROYECTO DE GRADO

2.2. SOBRE LA INTRODUCCION DE LA TESIS

2.2. SOBRE EL TITULO DE LA TESIS

2.3. PLANTEAR OBJETIVOS GENERALES Y ESPECIFICOS

Esta clasificacion fue tomada de http://www.virtual.unal.edu.co/cursos/enfermeria/2002847/lecciones/tematica4/subtema4-8.html

2.4. OTRAS COSAS SOBRE LOS OBJETIVOS ESPECIFICOS

2.5. CUIDADOS AL PLANTEAR EL ALCANCE DEL PROYECTO

2.6. COSAS HA TENER EN CUENTA PLANTEAMIENTO DEL PROBLEMA

EJEMPLO DESGLOSADO DE DESCRIPCION DEL PROBLEMA

2.7. COSAS SOBRE LAS DELIMITACIONES

2.8. SOBRE EL ALCANCE Y LAS DELIMITACIONES

2.9. COSAS SOBRE EL RIESGO

2.10. COSAS HA TENER EN CUENTA SOBRE EL MARCO HISTORICO

2.11. COSAS SOBRE EL MARCO CONCEPTUAL

2.12. COSAS SOBRE EL MARCO REFERENCIAL

2.13. COSAS SOBRE LOS COSTOS DEL PROYECTO

2.14. COSAS SOBRE LA FACTIBILIDAD OPERATIVA DEL PROYECTO

2.15. COSAS SOBRE LA METODOLOGIA

2.16. COSAS HA TENER EN CUENTA EN EL MODELAMIENTO

2.17. TALLER PROPUESTO PARA MEJORAR LA FASE DE PLANEACION DEL PROYECTO

Lista de verbos que aparecen en el titulo del proyecto

Llene la siguiente tabla: Acciones que debe desempear el sistema, pero

Lista de verbos que aparecen en el titulo del