miércoles, octubre 25, 2006

Ingeniería de software (8)

Tal vez medio copiando a Fuckowsky, o a Builes...
Y es que porqué no? El internet se convirtió en la imprenta personal de cada persona, lo cual me recuerda cuando Burns compra los medios de comunicación... jejeje.

Ahora bien

En un principio... cuando todo era caos, oscuridad y tubos de vacío. La gente que trabajaba con las computadoras podía reducirse a un número mínimo. Los trabajos podían ser desde desencriptar ENIGMA, como también calcular tablas para lanzamiento balística. Turing y los demás de la época estaban a un nivel de heroísmo igual al de cualquier otro soldado que hubiera ayudado a ganar la guerra

Posteriormente, la llegada de la integración a larga escala, permitió a cada cual tener la posibilidad de poseer su propia computadora. Aquellos que estaban dispuestos, podían comprar un kit al mejor estilo "hágalo ud mismo" y construir su computadora. La programación era la tarea fundamental.

Poco a poco, los genios del mercadeo y del dinero fácil se dijeron a sí mismos... "Porque no le damos una computadora a todos los seres ineptos???". Y claro, aquí estamos. Millones de hindúes ahora se dedican a hacer por outsourcing 2 cosas.

Programar
Servicios de CallCenter

La imagen es clara. Una sala con 80 computadoras 386 para que los programadores echen código al ritmo del tambor o del látigo (al mejor estilo de barco de remos persa) y unos cuantos salones al lado, otros hindúes, adiestrados para hablar "perfectamente" el idioma que les toque, recitando la misma retahíla de preguntas una y otra vez. (Conecto ud la computadora?, está seguro que esta encendida?)

No es curioso, que con la llegada de las "aplicaciones" el mundo de la computación de convirtió en un mundo totalmente oscuro para el no conocedor; Sin embargo Esta opacidad(termino tal vez mal traducido del Libro the Second Self de Sherry Turkle) no debería de esperarse del supuesto conocedor.

Inquietante, por no decir terrorífico resulta el hecho de que la opacidad de las computadoras se transmitió cual virus de ebola a los supuestos conocedores. Cada vez se encuentran mas "ingenieros de software" que no saben programar. Peor aún, hay algunos que creen que no lo necesitan.

Al parecer, de una u otra forma, surgieron ciertos mitos sobre la relación modelación-ingeniería de software. En algún momento, de pronto con la llegada de UML, quien sabe, la gente comenzó a imaginarse al ingeniero de software de una forma surreal.

Llega la pequeña empresa con algunos requerimientos-requisitos; sin embargo, como los pobres y asociales programadores les queda imposible comprender que es lo que quiere aquel gerente de saco y corbata. Lo mandan donde el "ingeniero de software". Este hace uso de sus tremendas habilidades para "elicitar requisitos", ponerlos en dibujitos, y escribir un montón de carreta institucional en un montón de "documentación" para que los programadores hagan el trabajo sucio. El de obrero.

Esa imagen viene tal vez de la falsa analogía con la construcción: "mientras los obreros pegan los ladrillos, los ingenieros hacen planos". Pero... ¿Porqué es acaso es falsa esta analogía?

2 razones principalmente.

UML es un mal lenguaje de modelación... es ambiguo, "dependiente del contexto", sobre específico.

Antes de decir porque UML es un mal lenguaje de modelación se deben diferenciar dos cosas. El uso pretendido del objeto en cuestión y el uso real. En este caso me limito al uso real, en el cual UML pasa a convertirse en un conjunto de "formas de hacer dibujos" (eliminemos el concepto formal detrás de él y lenguajes de restricciones como OCL).

Estos dibujos (llámense diagramas de secuencia, casos de uso, diagramas de clase... blablabla) caen en el problema descrito por todos los lenguajes gráficos, el modelo es específico y no permite abstraer la situación proyectada. Tomando las palabras de un comunicado que hizo Djkstra alguna vez, con el modelo gráfico nunca se puede dibujar el triangulo arbitrario, siempre que se dibuje el triangulo será obtuso, rectángulo, isósceles... igual sucede con un modelo de clases o de casos de uso... no se abstrae el hecho transaccional de producto = factura sino que hasta se requiere dibujar un muñequito que será el vendedor!!!! (Soy yo el único que cree que un ingeniero no tiene porque quedarse dibujando muñequitos en el trabajo?)

Cómo sería el plano de construcción civil UML? Tal vez los lugares donde van las puertas tendrían muñequitos de palitos abriendo y cerrándolas para mostrar la "funcionalidad" (sino los obreros como saben que ahí hay una puerta?) Habría "notas UML" que dirían cosas como (la gente no camina en los techos) (esta viga debe ser de concreto) (este lado es arriba)

A diferencia de UML, el plano de construcción (y me refiero al plano ingeniería, no al arquitectónico) este refleja lo que se piensa realizar. Sin entrar en detalles que a la hora de la construcción resultan inútiles...

Perfectamente la inclusión de tanto lenguaje natural en el modelo UML lleva a interminables discusiones que se limitan a la misma ambigüedad del lenguaje natural. De hecho, nunca he entendido siquiera como un lenguaje de modelación puede siquiera imaginar tener lenguaje natural en forma embebida!!

UML no permite verificación ni evaluación

A diferencia de los métodos formales de Modelación como Z, Los diagramas UML no permiten verificación formal. No se puede establecer si en efecto los muñequitos que se dibujaron en el caso de uso reflejan el escenario a modelar.

El plano de construcción permite calcular cargas, escoger materiales, redefinir dimensiones, calcular centro de masa, ocupación máxima... Z permite realizar demostraciones sobre partes o la totalidad del "programa" y dan cuenta de la "correctitud".

Para finalizar y Siguiendo uno la definición de La Wiki...

"La Ingeniería de software es la rama de la ingeniería que crea y mantiene las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos."

Notación no es ciencia
UML es notación
UML no es ciencia ni la ingenieria de software UML


sábado, octubre 21, 2006

Mudanza

Bueno, al parecer me voy a mover para Blogger... es como mas lindo, no se myspace quedará en el pasado :P