documentacion de sistemas (programacion orientada a objetos)
Estela Padilla
Ya he desarrollado un proyecto en visual basic con base de datos de access,
pero ahora como lo documento. Me podrian aconsejar algun libro o algun sitio
donde consultar este tema.
Gracias.
Coatl
Documentacion de que tipo?
En el mundo ideal, tu documentacion la vas realizando mientras elaboras tu
proyecto, de hecho todo el analisis y diseño, especificaciones, diagramas de
casos de uso, de clase y demas deben ser requisito para la fase de
construccion (desarrollo) de tu sistema. En analogia a una casa, representan
los planos (estas de acuerdo que no puedes construir una casa decente sin
planos ...).
Como mencionas que estas utilizando OOP, puedes conseguir un libro de Grady
Booch sobre este tema, para si te vas a dedicar al desarrollo de forma
seria, te recomiendo que empiezes a checar toda la cultura de UML:
http://www.rational.com/uml/index.jtmpl
--
Alberto Borbolla
Microsoft VB MVP
Xco...@mvps.org (replace X to send mail)
Intersoftware Consulting
http://www.intersoftware.com.mx
"Estela Padilla" <epla...@hotmail.com> escribió en el mensaje
news:OMPKsxI$$GA.276@cppssbbsa05...
Daniel Oliver Rojas E.
gente que enseña como documentar
jamas a hecho una aplicación de verdad, lo mejor es que el Codigo lo
documenttes pensando Alguien mas lo va a ver
así que voy a poner comentarios de modo que lo pueda entender. Para la base
de datos porque no haces un procedimiento en una tabla cuelgue todas las
tablas y los campos de la base de datos y despues solo documentas
cada tabla y cada campo explicando para que sirve cada uno y describes las
relaciones que hay entre ellos.
"Coatl" <Xco...@mvps.org> escribió en el mensaje
news:OTvfH#J$$GA.288@cppssbbsa04...
Leonardo Azpurua
La gente que puede enseñar cómo documentar, aprendió porque lo encontró
necesario.
La necesidad de documentar se origina en la administración de proyectos
grandes o complejos.
La gente que desarrolla proyectos grandes o complejos, evidentemente, ha
hecho aplicaciones de verdad.
¿Por qué dices esas burradas?
Probablemente, porque nunca has necesitado documentar de verdad un proyecto,
o porque jamás has tenido que retomar un proyecto empezado por otra gente
que pensaba que bastaba con poner sus comentarios para que el programa
resultara inteligible.
La falta de documentación, por lo menos de las clases y de sus protocolos
(diagramas de colaboración o de secuencia) es imprescindible cuando el
proyecto supera el nivel de "trivialidad". Normalmente parto de un diseño
esquemático, pero de vez en cuando tengo que parar y dedicarle un par de
días a actualizar la documentación formal del proyecto y a detallar un poco
más el diseño: de otra manera sería imposible terminarlo.
Salud!
Daniel Oliver Rojas E. escribió en mensaje ...
Coatl
"Daniel Oliver Rojas E." <dan...@correo.de> escribió en el mensaje
news:e9sQ5EK$$GA.88@cppssbbsa05...
> Conosco la forma de documentar en UML, y OPP, pero te aconsejo algo, la
> gente que enseña como documentar
> jamas a hecho una aplicación de verdad,
Bueno, conozco gente que da cursos de UML y que lleva 10 años desarrollando
aplicaciones nivel entreprise ... asi que pondria en duda la veracidad de tu
afirmación ...
>lo mejor es que el Codigo lo
> documenttes pensando Alguien mas lo va a ver
> así que voy a poner comentarios de modo que lo pueda entender.
Si no utilizas una metodologia, esto no sirve de mucho, sobre todo como
comenta Leonardo, mas alla del sistemita de 5 formas y 3 modulos, cualquier
aplicacion de tamaño decente (sobre todo una usando OOP) requiera una
documentacion precisa y basada en una metodologia.
Daniel Oliver Rojas E.
o menos grandes que cumplen la norma ISO-9003) que se están comercializando,
y a partir de que me impusieron un modelo de desarrollo por el cual tuve que
sufrir enormes costos, tuve que diseñar mi propio sistema, de Análisis,
Desarrollo y Elaboración de Software en cualquier modelo que existe dejan al
programador en último termino porque es el codificador en un mundo de Jefe
de desarrollo, Analista, Diseñador, Codificador, Testers etc. Hace que los
costos en la vida real se disparen. Considero además que en este mundo cruel
al programador de vocación, al que ahora quieren llamar Ingeniero de
Software, lo desprecian, desprecian la habilidad que acumula durante años.
He descubierto que los modelos de desarrollo no funcionan y la mejor forma
es precisamente no tener un modelo si no que hay que adaptarse a necesidades
de presupuesto del cliente, tiempo, espacio físico, el equipo, etc. Lo único
de los modelos que me ha funcionado y que obviamente he modificado para mi,
es el de los prototipos y te voy a explicar porque.
1.- Cuando se inicia un desarrollo hay que realizar una exhaustiva
recopilación de requerimientos.
2.- Tratar de desarrollar un prototipo lo más rápido posible (aquí algo que
se le escapa a los otros modelos es que no siempre los desarrolladores
tienen una buena idea de cómo hay que hacer algo, o los programadores no
saben que no pueden hacer algo que parecía al principio muy sencillo)
3.- Mostrar al cliente el resultado indicando que se trata de una beta, aquí
se modifica el proceso anterior.
4.- De acuerdo al Software desarrollado se crean reglas de programación en
donde se establecen los estándares, (el equipo de desarrollo para esta
ocasión saben que su código apesta pero al final ya tienen una idea clara de
que cosa debe ser común a todos incluyendo los comentarios y documentación)
5.- Se crea desde un principio (de nuevo completo) el Software esta ves
mejorando en todos sentidos, documentación, estructura del código, velocidad
de operación, se crea rutinas genéricas a través de objetos o de funciones.
(o sea en este momento saben como hacerlo )
Seria muy largo explicarte, pero con esto lo que quiero decir, es que el
programador debe buscar su propio camino y no ponerse un caparazón en el
mundo de las computadoras el programador es el Rey, debe de rescatarse el
espíritu Hacker de los 70´s, debe de dejar de menospreciarse al Programador
que actualmente ni siquiera existe una carrera en donde al terminar recibas
un titulo de Lic. En programación.
Solo para que te des una idea, en la empresa donde trabajaba bajo el modelo
UML llevan desarrollando un software 2 años, que a mí me tomo junto con un
compañero algo así como 60 días. Y que conste que tenemos todo documentado
lo que seria el análisis y las relaciones entre clases (me gusta el estilo
de Microsoft en este sentido).
Se que tengo un punto de vista rebelde, pero creo que ya es tiempo de que
alguien le de su lugar a la gente que le gusta programar.
y conste que no digo que no hay que documentar, solo digo que el programador
no se debe guiar por nadie en este sentido ya que lo que para un autor es
bueno, en la vida real a veces se vuelve imposible llevarlo a la practica. y
el mejor modelo de documentación que he encontrado es este (me preguntaron
cuando la aplicación ya esta terminada) documentar (y programar) pensando
que cualquiera va a ver lo que yo hice.
Bye :-)
"Leonardo Azpurua" <lazp...@cantv.net> escribió en el mensaje
news:e0Y6F7U$$GA.247@cppssbbsa04...
> Daniel:
>
> La gente que puede enseñar cómo documentar, aprendió porque lo encontró
> necesario.
> La necesidad de documentar se origina en la administración de proyectos
> grandes o complejos.
> La gente que desarrolla proyectos grandes o complejos, evidentemente, ha
> hecho aplicaciones de verdad.
>
> ¿Por qué dices esas burradas?
>
> Probablemente, porque nunca has necesitado documentar de verdad un
proyecto,
> o porque jamás has tenido que retomar un proyecto empezado por otra gente
> que pensaba que bastaba con poner sus comentarios para que el programa
> resultara inteligible.
>
> La falta de documentación, por lo menos de las clases y de sus protocolos
> (diagramas de colaboración o de secuencia) es imprescindible cuando el
> proyecto supera el nivel de "trivialidad". Normalmente parto de un diseño
> esquemático, pero de vez en cuando tengo que parar y dedicarle un par de
> días a actualizar la documentación formal del proyecto y a detallar un
poco
> más el diseño: de otra manera sería imposible terminarlo.
>
> Salud!
>
>
> Daniel Oliver Rojas E. escribió en mensaje ...
> >Conosco la forma de documentar en UML, y OPP, pero te aconsejo algo, la
> >gente que enseña como documentar
> >jamas a hecho una aplicación de verdad, lo mejor es que el Codigo lo
Estela Padilla
Por cada sistema que he desarrollado, hago un diagrama de flujo (usando las
llamadas burbujas) mostrando como se mueven entre las actividades las
estructuras de datos. Hago otro esquema describiendo las caracteristicas de
todos los datos de todas las tablas.
Para la programacion estructurada yo documentaba el flujo de programas ya
que uno seguia de tras de otro o se encontraban en el mismo nivel. Pero esto
no puede aplicar para la POO, aqui es donde yo tengo problemas en como
documentar formularios, clases o diseñadores, la parte tecnica del sistema.
Si existe un diagrama propuesto por alguien o algun formato para describir
los elementos del sistema.
Espero sus comentarios. Gracias.
Coatl <Xco...@mvps.org> escribió en el mensaje de noticias
OTvfH#J$$GA.288@cppssbbsa04...
> Documentacion de que tipo?
> En el mundo ideal, tu documentacion la vas realizando mientras elaboras tu
> proyecto, de hecho todo el analisis y diseño, especificaciones, diagramas
de
> casos de uso, de clase y demas deben ser requisito para la fase de
> construccion (desarrollo) de tu sistema. En analogia a una casa,
representan
> los planos (estas de acuerdo que no puedes construir una casa decente sin
> planos ...).
> Como mencionas que estas utilizando OOP, puedes conseguir un libro de
Grady
> Booch sobre este tema, para si te vas a dedicar al desarrollo de forma
> seria, te recomiendo que empiezes a checar toda la cultura de UML:
>
> http://www.rational.com/uml/index.jtmpl
>
>
>
> --
> Alberto Borbolla
> Microsoft VB MVP
> Xco...@mvps.org (replace X to send mail)
> Intersoftware Consulting
> http://www.intersoftware.com.mx
>
Estela Padilla
y cual es la forma que tu conoces para documentar OPP ? es un diagrama ?
Daniel Oliver Rojas E. <dan...@correo.de> escribió en el mensaje de noticias
e9sQ5EK$$GA.88@cppssbbsa05...
> Conosco la forma de documentar en UML, y OPP, pero te aconsejo algo, la
> gente que enseña como documentar
> jamas a hecho una aplicación de verdad, lo mejor es que el Codigo lo
> documenttes pensando Alguien mas lo va a ver
> así que voy a poner comentarios de modo que lo pueda entender. Para la
base
> de datos porque no haces un procedimiento en una tabla cuelgue todas las
> tablas y los campos de la base de datos y despues solo documentas
> cada tabla y cada campo explicando para que sirve cada uno y describes las
> relaciones que hay entre ellos.
>
> "Coatl" <Xco...@mvps.org> escribió en el mensaje
> news:OTvfH#J$$GA.288@cppssbbsa04...
Estela Padilla
palabras no.
Ademas es util por donde lo veas, como evidencia de tu trabajo, el alcance,
incluso cuando la estas haciendo te pueden saltar a la vista errores o ideas
que te ayudan a mejorar lo que ya tienes. Estas y otras cosas mas.
Lo a mi me pasa es que no tengo la menor idea de como documentar la parte
tecnica de la programacion (formularios, procedimientos que ahora pueden ser
clases). Aqui es donde necesito su ayuda. Con la programacion estructurada
pues no habia mucho problema pero con la orientada a objetos, como?
epl.
Leonardo Azpurua <lazp...@cantv.net> escribió en el mensaje de noticias
e0Y6F7U$$GA.247@cppssbbsa04...
> Daniel:
>
> La gente que puede enseñar cómo documentar, aprendió porque lo encontró
> necesario.
> La necesidad de documentar se origina en la administración de proyectos
> grandes o complejos.
> La gente que desarrolla proyectos grandes o complejos, evidentemente, ha
> hecho aplicaciones de verdad.
>
> ¿Por qué dices esas burradas?
>
> Probablemente, porque nunca has necesitado documentar de verdad un
proyecto,
> o porque jamás has tenido que retomar un proyecto empezado por otra gente
> que pensaba que bastaba con poner sus comentarios para que el programa
> resultara inteligible.
>
> La falta de documentación, por lo menos de las clases y de sus protocolos
> (diagramas de colaboración o de secuencia) es imprescindible cuando el
> proyecto supera el nivel de "trivialidad". Normalmente parto de un diseño
> esquemático, pero de vez en cuando tengo que parar y dedicarle un par de
> días a actualizar la documentación formal del proyecto y a detallar un
poco
> más el diseño: de otra manera sería imposible terminarlo.
>
> Salud!
>
>
> Daniel Oliver Rojas E. escribió en mensaje ...
Estela Padilla
Eso es lo que a mi me interesa, la metodologia para documentar sistemas
programados con orientacion a objetos.
Espero su ayuda. Gracias.
Coatl <Xco...@mvps.org> escribió en el mensaje de noticias
uvGxCFW$$GA.261@cppssbbsa05...
>
> "Daniel Oliver Rojas E." <dan...@correo.de> escribió en el mensaje
> news:e9sQ5EK$$GA.88@cppssbbsa05...
> > Conosco la forma de documentar en UML, y OPP, pero te aconsejo algo, la
> > gente que enseña como documentar
> > jamas a hecho una aplicación de verdad,
>
> Bueno, conozco gente que da cursos de UML y que lleva 10 años
desarrollando
> aplicaciones nivel entreprise ... asi que pondria en duda la veracidad de
tu
> afirmación ...
>
> >lo mejor es que el Codigo lo
> > documenttes pensando Alguien mas lo va a ver
> > así que voy a poner comentarios de modo que lo pueda entender.
>
> Si no utilizas una metodologia, esto no sirve de mucho, sobre todo como
> comenta Leonardo, mas alla del sistemita de 5 formas y 3 modulos,
cualquier
> aplicacion de tamaño decente (sobre todo una usando OOP) requiera una
> documentacion precisa y basada en una metodologia.
>
>
Estela Padilla
Daniel Oliver Rojas E. <dan...@correo.de> escribió en el mensaje de noticias
eYeFPSW$$GA.250@cppssbbsa05...
Coatl
news:et6QtAX$$GA.274@cppssbbsa05...
> Gracias por sus comentarios, pero creo que no me explique bien.
>
> Por cada sistema que he desarrollado, hago un diagrama de flujo (usando
las
> llamadas burbujas) mostrando como se mueven entre las actividades las
> estructuras de datos. Hago otro esquema describiendo las caracteristicas
de
> todos los datos de todas las tablas.
>
> Para la programacion estructurada yo documentaba el flujo de programas ya
> que uno seguia de tras de otro o se encontraban en el mismo nivel. Pero
esto
> no puede aplicar para la POO
Exacto, no puedes utilizar tecnicas de programacion estructurada para
programar OOP, de la misma forma no puedes usar tecnicas de documentacion y
modelado que no tienen en mente OOP.
Por ejemplo, el UML (Unified Model Language), que no es otra cosa que un
lenguaje de modelado que unifica tres tecnicas de modelado diferentes (los
llamados "tres amigos"), contempla el uso de diagramas de sequencias de
eventos, diagramas de clase donde puedes representar las relaciones
(estereotipos) entre clases.
No hay mucha documentacion al respecto sobre UML en español y en ingles,
pues la liga que envie en un post anterior, para empezar puedes utilizar los
diagramas de Booch (el cual tiene varios libros al respecto), los cuales
estan mas orientados a documentar tu estructura de clases (en este instante
probablemente no te interesaria tanto la parte de modelacion, ya que ya
tienes desarrollada tu aplicacion).
Coatl
news:eYeFPSW$$GA.250@cppssbbsa05...
> sufrir enormes costos, tuve que diseñar mi propio sistema, de Análisis,
> Desarrollo y Elaboración de Software en cualquier modelo que existe dejan
al
> programador en último termino porque es el codificador en un mundo de Jefe
> de desarrollo, Analista, Diseñador, Codificador, Testers etc.
Depende del tipo de aplicacion, pero en general, de nada sirve que tengas
programadores master++ si tu problema no fue bien modelado, si no se hizo un
procedimiento adecuado de obtencion de requerimientos y alcances con el
cliente.
El proceso de desarrollo de software es mucho mas que la programacion.
>Hace que los costos en la vida real se disparen.
Esto es inevitable, tienes que definir un proceso de desarrollo, con gente
destinada para manejo de calidad, etc ...
De lo contrario corres el riesgo (bastante alto) que tu sistema no se
implemente. Como prueba las estadisticas de porcentaje de exito/fracaso de
los sistemas en los ultimos años. (abundan referencias al respecto)
>Considero además que en este mundo cruel
> al programador de vocación, al que ahora quieren llamar Ingeniero de
> Software, lo desprecian, desprecian la habilidad que acumula durante años.
Es obvio que alguien con el suficiente criterio y habilidad debe saber
cuando alguna norma o estandar causa mas problemas que ventajas, pero esto
depende mucho de la experiencia, cuantos programadores conoces con estos
atributos? que porcentaje de la gente que desarrollo, tiene realmente la
vocacion de programador?
> He descubierto que los modelos de desarrollo no funcionan y la mejor forma
> es precisamente no tener un modelo si no que hay que adaptarse a
necesidades
> de presupuesto del cliente, tiempo, espacio físico, el equipo, etc.
Es una de las principales habilidades que debe tener un "Ing. de Software"
(o si quieres llamarle tu programador)
>Lo único de los modelos que me ha funcionado y que obviamente he modificado
para mi,
> es el de los prototipos y te voy a explicar porque.
La tecnica de prototipos es contemplada por varias metodologias por sus
ventajas.
>es que el programador debe buscar su propio camino y no ponerse un
caparazón en el
> mundo de las computadoras el programador es el Rey, debe de rescatarse el
> espíritu Hacker de los 70´s,
Nop. ese esquema no funciona, las estadisticas lo demuestran.
Un esquema en el cual el programador es el centro del universo, solo es
válido cuando cuentas con un equipo de programadores con gran experiencia (y
aun asi tengo mis dudas), y con un conjunto de habilidades extremadamente
amplio (cuantos proyectos han fracasado simplemente porque el programador no
tiene las habilidades humanas necesarias para "bajarse" al nivel del cliente
y poder obtener los requerimientos necesarios).
>debe de dejar de menospreciarse al Programador
> que actualmente ni siquiera existe una carrera en donde al terminar
recibas
> un titulo de Lic. En programación.
Quizas el problema sea de terminos, que es para ti un programador? que no es
lo mismo que un ing. de software?
Cuales son para ti las diferencias?
>
> Solo para que te des una idea, en la empresa donde trabajaba bajo el
modelo
> UML llevan desarrollando un software 2 años, que a mí me tomo junto con un
> compañero algo así como 60 días. Y que conste que tenemos todo documentado
> lo que seria el análisis y las relaciones entre clases (me gusta el estilo
> de Microsoft en este sentido)
No puedes depender de gente con gran talento para implementar una solucion.
(cuanta gente con estas caracteristicas hay?)
> Se que tengo un punto de vista rebelde, pero creo que ya es tiempo de que
> alguien le de su lugar a la gente que le gusta programar.
Para determinado tipo de aplicaciones (utilerias, S.O., manejo de
dispositivos y demas) ahi esta el dominio de este "super programado", porque
Linux no ha conseguido entrar en el mercado del cliente?
Porque los "superprogramadores" de Linux tienen una excelente idea de lo que
es TCP/IP pero muy poca de conceptos relacionados con un usuario final,
cuando la gente de Linux domine estos conceptos entonces si cuidado para MS
en estos nichos.
Leonardo Azpurua
Hola, Estela:
En esta discusión se ha mencionado mucho a Grady Booch. Un libro suyo,
llamado "Análisis y Diseño Orientado a Objetos con Aplicaciones (2ª
Edición)", Ed. Limusa - Wiley, Mexico, fue algo así como la síntesis que me
permitió acceder al pensamiento OO. Ilustra cada uno de los conceptos de la
OO y diferentes técnicas para su representación gráfica. Aunque tiene ya
varios años, es un libro excelente, sobre todo por lo exahustivo de sus
explicaciones, y lo prágmatico de su enfoque.
Date una pasada por www.rational.com, además de poder bajarte las
especificaciones formales de UML (Unified Modelling Language), puedes
bajarte una copia de demostración de Rational Rose, una herramienta
excelente para apoyar todas las fases del desarrollo.
En lo personal, combino una cantidad de técnicas heredadas de los métodos
estructurados (los DFD, por ejemplo, nunca demasiado detallados), los
Autómatas de Estado Finito -tomados de las técnicas de análisis sintáctico,
y empleados para definir las posibles variantes en la ejecución de una
determinada operación (en UML se replantean como "Diagramas de Transición de
Estados"), con técnicas netamente OO como los diagramas de especificaciones
de clases y los diagramas de secuencia y de colaboración. Además de las
imprescindibles definiciones de requerimientos en lenguaje natural
formalizado.
En algo tiene razón Daniel, y es en que -a menos que el proyecto sea
realmente grande o sumamente complejo- una técnica formal de análisis o
documentación entorpece más de lo que ayuda. Hay que mantener siempre un
balance entre el ideal teórico y el requerimiento o la capacidad reales.
De momento, esoty trabajando un esquema en el cual las clases, tanto a nivel
de aplicación como de modelado de la empresa, se dividen en Operaciones,
Entidades y Servicios. Las formas son la interfaz de esas clases con el
mundo exterior. De esta manera, sólo tengo que pensar en clases (aunque en
el caso de las operaciones, el elemento más importante de la clase sea
justamente la forma), es decir, en una sola categoría de abstracción. Luego
resulta que diferentes entidades tienen una cantidad de propiedades comunes,
entonces creo una clase abstracta y redefino las entidades como
implementaciones de esas clases (es una forma limitada de usar la herencia
en VB, curiosamente, la encuentro mucho más natural que en otros lenguajes).
Pero es cuestión de enfoque.
Salud!
Leonardo
---------------------------------------------
Estela Padilla escribió en mensaje ...
Daniel Oliver Rojas
Creo que cause una pequeña polémica y eso es bueno, mi intención
no es decir que no se debe de documentar el Software, pero creo que aquí hay
una confusión, no se trata de documentar, de evitar un modelo si no de
realizar una mezcla de lo mejor de todos.
UML es Unified Modeling Language, se basa en el Análisis Orientado a
Objetos, si lo dominas es mas caro el Analisis que el Software terminado.
1.- Consulta las siguientes ligas
http://www.lab.dit.upm.es/~labscom/almacen/sld/uml/index.htm
http://bautista.dcs.fi.uva.es/~mlaguna/is2/materiales/glosario.htm
Yo no digo que el método no funcione pero, existen limites que cuando se
vive de programar (a mi nadie me paga un sueldo fijo recibo mis ingresos
únicamente de mi capacidad de desarrollar sistemas) y créanme cuando lo ves
del lado de los costos cambias del modo de pensar académico y te estrellas
con la realidad. Díganme cuantos de ustedes programan en Tres capas, tienen
Sus requerimientos, tienen un grupo de diseñadores y testers, usuarios
expertos, recopilación de requerimientos, escenarios, actores, diagramas de
secuencia, diccionarios de datos, sus documentos de relaciones entre clases,
sus diagramas de proyectos con hitos y recursos, tiempos asignados de los
recursos, cálculos de gastos, ya que todo esto y mucho más representan la
documentación de un proyecto. Les apuesto que sin querer hicieron lo que
dije tomaron un estilo propio que ha funcionado y reitero mi recomendación a
Estela Padilla, conoce los modelos de desarrollo pero utiliza el propio.
Me desconecte por un tiempo perdón por responder hasta hoy
Leonardo Azpurua
Hola, Daniel:
Daniel Oliver Rojas escribió en mensaje ...
> mi intención no es decir que no se debe de documentar el Software, pero
creo que aquí hay
>una confusión, no se trata de documentar, de evitar un modelo si no de
realizar una mezcla de lo mejor de
> todos.
En eso estamos de acuerdo, aunque definitivamente no es eso lo que decía tu
primer mensaje.
>UML es Unified Modeling Language, se basa en el Análisis Orientado a
>Objetos, si lo dominas es mas caro el Analisis que el Software terminado.
Nuevamente, dominarlo no es tragárselo entero. Dominarlo es conocerlo lo
suficientemente para saber qué te ofrece, y tomar lo que te convenga.
>Yo no digo que el método no funcione pero, existen limites que cuando se
>vive de programar (a mi nadie me paga un sueldo fijo recibo mis ingresos
>únicamente de mi capacidad de desarrollar sistemas) y créanme cuando lo ves
>del lado de los costos cambias del modo de pensar académico y te estrellas
>con la realidad.
No creo que el estudio y el uso de UML (adaptado a las propias
necesidades) y un cierto rigor formal en la metodología de desarrollo
respondan a un "modo de pensar académico". De hecho, cada vez es más difícil
ganarse la vida programando si no tienes una base metodológica probada y
funcional.
En la práctica del oficio, al menos en nuestros países, invariablemente
se acaba encasillado dentro de un tipo de aplicación (en mi caso son los
sistemas para negocios, y si no lo supieras te sorprendería saber cuán
similares son, por ejemplo, un comercio al detal, un expendio de comida
rápida, una fábrica, un banco o una línea aérea). Si quieres ser eficiente
en ese universo, tienes que buscar la "reusabilidad". La reusabilidad te la
da el buen diseño, particularmente una granularidad relativamente alta y un
nivel mínimo de cohesión entre los modulos.
Cuanto mayor es la presión para ganarse la vida, tanto mayor debe ser la
urgencia para "normalizar" tus métodos de desarrollo. Quitando el uso de
personal adicional (no tengo ayuda en las fases de diseño y codificacion)
trato de mantener la estructura de tres capas lo más diferenciada posible
(sí, a veces me la salto), verifico los modelos con usuarios expertos,
escribo mis requerimientos lo más formalmente posible, realizo instalaciones
beta en varias empresas, uso diagramas de clases, de transiciones de estado
y de secuencias, y no me queda más remedio que calcular los costos y tiempos
de desarrollo (¿cómo, si no, se cuánto debo cobrar por un desarrollo o
adaptación?); afortunadamente, las BD modernas documentan los datos y las
relaciones. ¡No imagino de qué otro modo iba a poder manejar la complejidad
de las aplicaciones que escribo!
¿Tu no haces estas cosas?
Saludos
Leonardo Azpurua
Daniel Oliver Rojas
pensar se deba a que estoy entre dos mundos, linux y MIcrosoft y es como
estar casado y ser infiel. Si la discución es buena pero creo que la
programación es una vocación, que debe de ser tomada mas en cuenta como una
profeción de verdad, no cualquiera programa y eso lo sabes muy bien (y
bien). e insisto cada quien debe de crear su propio camino no en negar las
cosas que puedan ser buenas pero jamas hacerlo de manera riguroza como me
paso a mi, en donde te atan de manos y te dicen que es lo que tienes que
hacer como si fueras una maquina, yo pienso que el programar tambien lleva
inventiva y creatividad que a la mayor parte de la gente que crea sus
modelos de desarrollo se les olvida.
Leonardo Azpurua
Creo que hemos debido llevar esta discusión a través de nuestros correos
desde hace un par de mensajes, pero no se si "correo.de" es un dominio
válido.
De los principios generales de la documentacion de sistemas OO hemos
venido decayendo hasta un punto que me aburre: los alcances y límites de un
tipo que lleva la etiqueta de "programador".
Una vez, hace ya veintisiete años, me dieron un papel que decía que yo
era "Programador de Computadoras". Un papel válido sólamente ante la
academia que lo emitió, que además dictaba cursos de Secretariado, Inglés
Comercial y Taquigrafía. Sabía hacer diagramas de flujo, conocía las
sintaxis de COBOL, FORTRAN y RPG-II, algunos hitos de aquella historia de
Holerith a Aitken, y sabía escribir procedimientos de "Actualización por
Línea Balanceada" y "Rupturas de Control". Si un programador es eso, razón
hay para que lo lleven con la rienda cortita y muy supervisado.
Si uno se preocupa por su oficio, si se da uno cuenta de su interminable
ignorancia y hace algo por solucionarla, estudiará todo lo que sea
necesario, estará al tanto de los últimos cambios teóricos en su disciplina,
se esforzará por encontrar maneras de hacer las cosas mejor. Todo eso te
lleva a dedicar buena parte del tiempo a estudiar, y a ser cada vez más
detallista y más minucioso en el proceso de desarrollo.
La mayor parte de los estándares de desarrollo actuales surgieron de la
práctica, es decir, de las necesidades de desarrolladores reales en
proyectos reales.
UML, por ejemplo, no es una metodología; es un lenguaje para comunicar
los productos del análisis y diseño de un sistema, realizados según la
metodología de A&DOO unificada de Booch, Rumbaugh y Jakobson. Su se debe a
que fue concebido como un estandard para orientar el proceso de desarrollo
de herramientas CASE que apoyen esa metodología. Visto de esa manera, no
resulta tan innecesariamente complicado como cuando se ve como algo que hay
que estudiar para poder programar. Un producto basado en UML, por ejemplo,
es Rational Rose. Y es innegable que cuánto más ampliamente lo uses y cuanto
más te apoyes en él para diseñar tus proyectos, tanto mayores serán tus
posibilidades de éxito y la calidad de tus productos.
Tampoco veo una gran diferencia entre programar para Linux o para
Windows, ni entre programar en "C" viejo o en Visual Basic. Mi último
sistema en "C", con versiones para DOS y UNIX, es tan orientado a objetos
(en su diseño y estructura) como las cosas que ahora hago con VB. Los
componentes esenciales de nuestro oficio son el pensamiento y la
metodología, y ambas son independientes del lenguaje de programación
empleado y de la plataforma de destino.
El asunto de la "creatividad" es otra cuestión bizantina. Durante mis
primeros años como programador independiente, debo haber escrito centenares
de veces el proceso de una factura, y cada vez era más creativo que la
anterior. Tambien cada vez, la nueva era mejor, y la anterior se quedaba
como estaba. En un sistema relativamente grande llegué a la idiotez de
escribir tres procesos diferentes para el registro de las mismas facturas,
en tres contextos diferentes. Todo ello fue posible porque tenía una inmensa
confianza en mi "potencial creativo". Si desde el comienzo hubiera usado ese
potencial para desarrollar un estándar de proceso de las facturas que
pudiera haber ido mejorando y cuyas mejoras hubieran podido incorporarse
facilmente a los proyectos actuales y futuros tanto como a los anteriores,
habría trabajado muchísimo menos y casi ninguno de mis programas habría
muerto de obsolescencia. O sea, habría hecho más, con menos esfuerzo, y hoy
sería "menos pobre". Es como si un arquitecto comenzara el proceso de diseño
de cada nueva edificación inventando una nueva clase de ladrillo, o una
nueva máquina mezcladora de concreto. Si existen componentes sólidos que
hacen lo que necesitamos, qué estúpida manía es esa de querer reescribirlos
en nombre de la "creatividad". Si existen métodos probados para el diseño de
los sistemas, estándares racionales de codificación, principios para la
implementación, y si nuestra preocupación primordial es producir buen
software a tiempo, no veo dónde está nuestra ganancia al aplicar nuestra
"creatividad" para repetir, en general torpemente, todo el proceso que llevó
al establecimiento de esos métodos, estándares y principios, en vez de
adoptarlos práctica y humildemente.
Finalmente, creo que las diferencias entre quien se encasilla como
"programador", "analista" ,"ingeniero" o "integrador" se deben más a las
diferentes formas que la pasividad adopta en cada quien que a una diferencia
real en el tipo o nivel de conocimientos requeridos en cada caso. Todas esas
circunstancias obedecen más a cuestiones relacionadas con el poder, la
división del trabajo y la organización del aparato productivo que a la
práctica del oficio, que es lo único que en última instancia me importa.
Saludos!
Leonardo
Daniel Oliver Rojas
apasiona, es decir me interesa el hecho de querer realzar algo que como tu
dices es una carrera que en una escuela en donde también enseñan
secretariado y carpintería, es precisamente por eso que debería de tratar de
mejorar al medio.
Todo esto comenzó a raíz de que mencione que un programa (ya terminado
insisto) como se debería de documentar, y solo mencione que siguiera el
camino que quisiera, y sobre todo no le recomendé el método de UML, y lo
hice así precisamente porque sabia que iba a desatar una polémica, todo el
texto que escribiste es bastante cierto, yo también he aprendido muchas
cosas que me ahorran tiempo y esfuerzo (sobre todo la re utilización de
componentes) solo quería hacer un poco de consciencia de lo que se considera
un movimiento underground de la gente que programa para linux, pero que casi
no ha tocado al resto de los programadores, el punto de la creatividad no
quiere decir que todo lo tengas que hacer re inventando el hilo negro, pero
debe de existir, hay cosas que simplemente no sabes como hacerlas, y que no
existen algoritmos inventados por alguien mas, entonces viene la parte
placentera (por lo menos para mí) que es ver como algo que no existía
funciona.
Si no programas con la pasión del principio cuando confiabas en tu
creatividad, entonces te pierdes de la parte divertida del asunto. Y no
confundas falta de experiencia con Creatividad, el hacer código
transportable , re utilizable, seguro, rápido y que consuma pocos recursos
creo que es el objetivo de todos pero además hay que hacer divertido el
asunto no crees.
Leonardo Azpurua
Hola, Daniel:
Es cierto que uno de mis temas favoritos es la práctica del oficio. Un poco
por eso sigo contestando a tus mensajes, a pesar de que considero que lo
hemos convertido en un diálogo totalmente fuera del tema del NG. Con
frecuencia he insistido en la observación de ciertas normas, y no me parece
coherente seguir con una discusión totalmente fuera de tópico. Te agradezco
que si quieres que sigamos con la discusión, lo hagamos por nuestros
respectivos correos personales, o si prefieres, la llevemos a
"microsoft.public.es.desarrollo", cuya definición es lo suficientemente
amplia para contener discusiones como la nuestra.
Siguiendo con el hilo: mi posición es que un profesional de la informática,
de la computación o de los sistemas, como lo llamamos en español con menos
diferenciación de la que deberíamos, puede dominar la totalidad del universo
de su oficio o puede no hacerlo. En el primer caso es un buen profesional;
en el segundo, sencillamente, no lo es.
La forma en la que uno se relaciona con el cuerpo de conocimientos que
engloba su disciplina no tiene nada que ver con la manera en la que haya
comenzado su aprendizaje. O no debería, porque en la práctica existen
diferencias entre las actitudes típicas de tipos como yo, "egresados" (si la
palabra no es demasiado grande) de cursos elementales y los profesionales
que han terminado una carrera completa. Los elementales tendemos a darle
mucha más importancia a la capacidad individual, a la creatividad y a la
inspiración. Los "profesionales", en cambio, aprecian por encima de todo el
método y la formalidad, hasta el último detalle. En igualdad de condiciones
y habiendo asimilado ambos una cantidad de experiencia equivalente, las
capacidades y actitudes de ambos tenderán a equilibrarse: el "elemental"
tenderá a asimilar métodos "académicos" (si no, el desorden acabrá con él, o
lo dejará en una posición limitadísima), y el "académico" aprenderá a
inventar soluciones creativas y a dejar muchas cosas en manos de "la
inspiración".
La inspiración y la creatividad son la esencia de nuestro oficio, no
importa a que nivel trabajes. Las mismas dosis de imaginación, inventiva y
rigor formal son necesarias para resolver la mejor manera de combinar n
flujos de datos en un proceso complejo con m salidas, que para diseñar la
estructura conceptual de alto nivel de un sistema complejo. Por eso no creo
en la conveniencia de levantar ninguna bandera a favor de tal actividad en
contra de tal otra. Sólo creo en el trabajo bien hecho, independientemente
de todas las circunstancias "políticas" a su alrededor.
Bueno...
Tengo que seguir en lo mío.
Salud!
quetxalco...@gmail.com
moira12...@gmail.com
Hola,
Yo estaría encantado de proporcionar préstamos a todos los necesitados .
De hecho, yo soy una mujer muy seria , a cambio le pediría que la gente
seria en contacto conmigo en mi correo electrónico privado para obtener
más información sobre el préstamo y las condiciones . Gracias ponerse en
contacto rápidamente con por correo : moira12...@gmail.com