Barrapunto

La penúltima noticia de Barrapunto, retrata el tema que apareció hace nada (http://barrapunto.com/softlibre/03/08/30/1448208. shtml) Y esta debe de ser para un pequeño colectivo, por que me he quedado de cuadros al leer el titular, aparte de no entender nada. Animos Barrapunto.

Lo primero, manifestar mi asombro al ver una "noticia" así en portada. ¿Qué pinta aquí una portada así? Hay noticias pendientes que no han sido publicadas y han sido de mucho más interés, y parece que se editan noticias que no vienen a cuento, otras poco contrastadas, etc... :(

Los casos de uso UML, personalmente hablando, no han sido de mucha utilidad. Al ser algo ambiguos, conviene acompañarlos de una explicación verbose de lo que es cada cosa. Más bien los considero como un dibujo ilustrativo de los escenarios escritos "verbose", y con otros diagramas de "cosecha propia" que sean más claros a la hora de, por ejemplo, expresar la interacción de los actores con el resto del escenario.

Tal vez sea porque UML no me hace demasiada gracia. Si, si, mucho estándar pero luego cada uno hace sus pequeñas modificaciones e interpretaciones.

Por cierto, como curiosidad, Umbrello será incluido de serie en las KDE 3.2. No es el Rational pero aun vale :)

Hola, no entro en lo de la noticia.

Me gustaria tener aplicaciones para "radiografiar" un enorme projecto de codigo en C. Algo que combierta miles de lineas de C en graficos para estudiarlos de un vistazo. Tambien programas o librerias para optimizar codigo. Ahora mismo tengo una libreria que sustituye a las funciones de de memoria dinamica (malloc y demas) que permite hacer logs y parece muy practica. Quizas alguien quiera ser amable y me quiera hablar de otras, multiplataforma si puede ser. [ He visto que el proyecto GNU tiene un profiler, pero no me termina de servir para mis propositos. ]. Solo es eso.

En primer lugar, me parece correctísimo y muy deseable que aparezcan este tipo de asuntos en portada. Creo que es necesaria una mayor concienciación en la necesidad de documentar el software antes que desarrollarlo. Los casos de uso yo los veo como una herramienta más en el desarrollo del software (sobre todo en las primeras etapas) que proporcionan una visión general de los requerimientos de un sistema. Cuando abordas un proyecto que te pasan puedes obtener una primera impresión de qué va el asunto. Sin embargo por sí solos no valen mucho: deben ir acompañados de diagramas y especificaciones para reflejar los comportamientos estáticos y dinámicos de un proyecto, es decir, de una Especificación de Requisitos del Software completa. Saludos.

Pienso que se debería pensar en 2 tipos de modelos, el modelo esencial y el modelo de implementación. Si se utiliza el caso de uso para indicar que hace el sistema al presionar un botón estamos hablando de modelo de implementación que no sirve en las primeras etapas de desarrollo donde se debe tener muy claro cual es el modelo esencial. Para realizar el modelo esencial el caso de uso es fundamental para indicar como debe responder el sistema ante ciertos eventos o estímulos que recibe del ambiente. Sería algo como un diagrama de contexto. Un alumno egresado de 9no año presenta documentación para inscribirse en 1ro polimodal. Esto sería un estímulo para un sistema de administración escolar de polimodal, donde tenemos al actor (egresado de 9no año) que estimula al sistema con la presentación de la documentación de inscripción. Como toda herramienta, el caso de uso debe ser utilizado donde corresponde y para la función que fue ideado. No deberíamos utilizar un serrucho para clavar un clavo, aunque se puede hacer....

A mi los casos de uso me parecen utiles para identificar el "que" del sistema el "como" ya se ira definiendo en siguientes etapas, gracias a los casos de uso se pueden identificar cuales son el resto de elementos con los que el sistema interactua y me ayudan a aclarar que funciones ofrece y a quien se las ofrece de una forma bastante concisa.

Además creo que como modelo de definición son bastante flexibles,es un modelo que se adapta bastante bien a casi cualquier sistema, en muchas ocasiones el gran problema de las metodologias de desarrollo es que obligan a que nuestro sistema se adapte al modelo lo que suele ser bastante antinatural y aportar más confusión que otra cosa.

En mi caso y en el de mis compañeros en la facultad la dificultad era que acababamos de pasar de una metodología no orientada a objetos a una UML (por ejemplo, en Málaga vimos Metrica 2 y después Metrica 3 cuando salió, o en 4º UML). El problema era que todo el mundo tendía a creer que los casos de uso (yo incluido) eran funciones del programa, es decir, que después se iban a traducir a procedimientos, métodos, funciones o como querais llamarle. Nada más lejos de la realidad. Un caso de uso es una cosa mucho más abstracta donde se intenta expresar PARA QUÉ va a usar el usuario (valga la rebuznancia) el sistema, con qué finalidad se acerca al programa y cuales son los pasos abstractos que tiene que seguir para hacerlo bien y obtener un resultado provechoso, y tambien prever qué puede ir mal. Mi consejo es no exagerar con los casos de uso y no atribuirles una importancia extrema, porque en realidad suelen servir para las entrevistas con el cliente.

Ricardo estalman ? juasss Respecto a lo que ha dicho alguien por aki del criterio para poner un noticia en portada totalmente de acuerdo hay noticias que no valen un churro.

En Internet podeís encontrar bastante material sobre UML, pero uno de los mejores libros gratis a mi criterio lo podeís encontrar aquí:

http://www.ariadnetraining.co.uk/books.htm [ariadnetraining.co.uk]

Yo me había currado unos Title (tampoco mucho) para cada enlace pero parece que Slash se los ha comido.