Lo estoy haciendo bien?????

[david_uh]

Empezado por nlsgarcia

al final las personas que viene a este foro buscan soluciones practicas a problemas reales y no simple disertación teórica que aunque necesaria en su momento, no es el objetivo final.

estoy de acuerdo, inicie este post con el fin de buscar una orientacion ya que no tengo claro aun como crear mis clases para este sistema de ventas usando oo, ya que nunca he usado este paradigma, y me siento perdido, siempre he programado en forma estructurada, he usado objetos pero hasta ahi nomas, y me preguntaba si mis clases que estoy creando van bien alguna observacion, etc. estoy conciente de los diferentes puntos de vista a la hora de modelar pero el hecho es que necesito ideas, criticas, observaciones, etc

Saludos

David

[[Delphius]]

Empezado por nlsgarcia

Delphius,
En la década de los 90 se crearon alrededor de 50 metodologías orientadas a objeto,

¿Eran tantas? Recuerdo que eran muchas pero no que llegasen a las 50

Empezado por nlsgarcia

pero gracias a la unificación que propuso UML se llego a un lenguaje de modelado visual que permite gran expresividad semántica gracias a la naturaleza de sus diagramas, la experiencia acumulada hasta el momento en A&D/OO y la necesidad de una herramienta que no limitara el análisis sino que lo apoyara y extendiera si era necesario según cada contexto particular.

Yo no estoy en contra del UML, todo lo contrario ¡apoyo y defiendo mi uso! Hasta me atreví a poner a modo de portada en mi cuenta de facebook la frase "UML es mi escudo y mi espada"
Creí que con mi resumen de historia dejaba en claro que UML se formalizó justamente con la intención de proponer algo estándar y que todos pudieran entender.
Que UML sea extensible es ya una cuestión secundaria, y por las circunstancias y su naturaleza.

Empezado por nlsgarcia

UML no pretende ser una metodología,

En ningún momento he dicho que lo fuera. Si lo hubiera dicho me reprobaría y me mandaría derecho a recursar Ingeniería de Software.

Empezado por nlsgarcia

tampoco considera que sus diagramas modelen en su totalidad todas los escenarios,

Tampoco dije que modele en su totalidad. Simplemente comenté que UML ofrece un amplio abanico de diagramas para representar a un sistema desde diversos puntos de vistas. Más esto no quiere decir que en su totalidad.

Empezado por nlsgarcia

es por ello que existe un apartado de mecanismo de extensión en el cual por medio de restricciones, valores etiquetados y estereotipos se puede extender el modelo visual para que se adapte mejor a un contexto particular, es decir: UML es extensible,

Seguramente sabes que si bien los esterotipos son un buen recurso, también pueden ser un arma de doble filo.

Empezado por nlsgarcia

los DFD y DER no pueden usar a UML,

Por supuesto que no. Si pudieran se estaría mezclando ambos lenguajes visuales, de dos paradigmas diferentes, y un tercero que es aplicable ya fuera del contexto de programación... me refiero al DER. Que está pensado para justamente no apegarse a ningún paradigma de desarrollo ni de programación.

Empezado por nlsgarcia

pero UML si puede usar a estos si se considera apropiado y de valor semántico con las adaptaciones correspondientes a elementos de UML.

El hacer un paralelismo entre procesos en un DFD y entidades en un DER con clases no esta lejos de la realidad, al final una clase es un conjunto de métodos y atributos que modelan por abstracción procesos y datos asociados en el mundo real de forma unisona por medio de un paradigma OO y UML permite por medio de los mecanismos de extensión, en este caso los estereotipos, hacer uso de nuevos elementos visuales con la salvedad de que estos nuevos elementos no forman parte del estándar UML y por consiguiente pueden prestarse a confusión y polémicas,

Precisamente debido al mezclar UML con capacidad de DER gracias a estereotipos es que las cosas se confunden. Por algo existe UML por un lado y por el otro el DER. Y justamente el estereotipo DER en UML es el más criticado y el que menos se recomienda utilizarlo que al final termina nublando y complicando más las cosas. El DER es más limpio y está pensado para representar base de datos.
Cada cosa en su lugar.
Los estereotipos como dije son armas de doble filo, e intentar adaptar UML hacia el paradigma estructurado para asimilar los DFDs es ir contra su corriente. Si en verdad se quiere pensar en estructurado ¡utiliza algo que está pensado para eso!

Empezado por nlsgarcia

pero es algo que se puede usar si se considera que aporta mayor expresividad semántica al análisis, no solo crear tus equivalentes de DFD y DER en UML basados en clases, sino crear cualquier elemento visual que se requiera con las restricciones mencionadas anteriormente.

No puedo estar a favor de eso. Entiendo tu punto, pero discrepo totalmente. Y una muy buena parte de la comunidad ya lo ha advertido... no por mucho poner estereotipos se consiguen mejores cosas.
Fabuloso que UML se vaya ampliando y mejorando, pero cada paradigma está para lo suyo.

Empezado por nlsgarcia

¿Hace falta en UML crear un equivalente basados en clases de los DFD y DER? : A UML no le hace falta

Precisamente no le hace falta porque no fue pensado ni diseñado para eso. De que se pueda, gracias a "extensiones" (y fuera del estándar) no quiere decir que se deba. Es un error conceptual, una cosa es el pensamiento estructurado y otra el OO. Al igual que cuando uno mezclas bebidas... alguien que vea OO + Estructurado le provocará nauseas y perderá la perspectiva. Es querer forzar a algo para lo que no es.

Empezado por nlsgarcia

pero desde un punto de vista estrictamente comunicacional y académico que permita plasmar dichos elementos de análisis como punto de partida y complemento del estándar UML es factible hacerlo,

Con más razón si dices que es académico: ¡NO MEZCLAR! Lo peor que puedes hacerles a los estudiantes es justamente presentarles UML con elementos del estructurado. Los estancas más. La idea es que se piense más en OO y no en OO estruturado. ¡No hay que acostumbrarlos! Porque luego es que se comenten justamente cosas como las que he señalado: se confuden y se mezclan cosas.

Empezado por nlsgarcia

sirve de punto de partida para el análisis y permite aclarar ideas si el área de experticia es el análisis estructurado.

Si la idea es enseñarles estructurado, entonces ¡dales las herramientas para eso!
Te lo podría aceptar si se tratase de una manera de hacer transición entre ambos paradigmas. Pero de allí en más, hay que evitar mezclar cosas. Y cuanto más limpio y estándar te mantengas, más fácil será comunicarte.

Empezado por nlsgarcia

Tener múltiples perspectivas ayudan y facilitan el modelamiento de un sistema, esa es la idea detrás de los estereotipos de UML y de sus mecanismos de extensión.

En eso estamos de acuerdo. UML fue pensado para ofrecer múltiples vistas. Pero hay que hacer las derivas advertencias sobre un abuso de estereotipos... ¡que se ha hablado mucho de eso! Por favor no los expongas como si fueran la gran solución cuando no lo es. UML tiene sus pros y contras... seamos sinceros. Pero los estereotipos se han puesto más como una medida forzada que una verdadera necesidad... no son la panacea.

Yo uso estereotipos, pero si puedo evitarme usarlos mejor.

[[Delphius]]

Empezado por nlsgarcia

La idea de UML es hacer el análisis y diseño orientado a objeto más fácil,

Tu lo has dicho: A/DOO no A/D estructurado. Un punto más a mi favor.

Empezado por nlsgarcia

sin limitaciones de metodología, adaptable a cualquier metodología y extensible para un mejor aprovechamiento de este, no lo contrario que fue lo que ocurrió en los 90 en el cual se dio un fuerte debate sobre el tema,

¿Por metodología a que te refieres? No entiendo lo que has querido decir...

Empezado por nlsgarcia

pero gracias a estas polémicas surgió UML como un estándar de modelamiento OO vigente hasta la fecha.

Nuevamente: Modelado para OO. Conste... que lo dices tu ¿he?

Empezado por nlsgarcia

Otros puntos:

1- Los Casos de Uso fueron creados por Ivar Jacobson en 1986 y usados por primera vez en 1992 en la metodología de diseño orientado a objetos OOSE (Object-Oriented Software Engineering) y posteriormente integrada a UML y RUP, aunque su uso nació dentro del ámbito OO se puede implementar en otras áreas como una forma de modelar procesos y eso es lo grandioso de UML y sus elementos: Se pueden usar como un lenguaje de modelamiento visual en otras áreas diferentes a la computación, lo cual muestra su flexibilidad y robustez semántica, pero lo cierto es que se usa principalmente el A&D/OO por ser algo propio de esta área.

¿Y en donde yo he dicho que los Casos de Uso son extrictamente OO? Si lees mis palabras encontrarás que he dicho que con la aparición de éste se le encontró potencial y se lo ha adoptado (que no integrado... que suena más extricto y de pertenencia). Como por ejemplo RUP, que lo utiliza como una de sus herramientas para recolectar requisitos. También he señalado que si bien UML ofrece un DCU (Diagrama de Caso de Uso) he recalcado que los CUs no son estrictamente hablando algo puro y exclusivo para OO.
Ha nacido en el ámbito OO, aunque no con la finalidad de ser exclusivo para dicho paradigma. Justamente evité exponer y decir semejante cosa al aclarar como por casualidades históricas y una mala interpretación y uso de dichas herramientas se formaron tantas confusiones.

Empezado por nlsgarcia

2- Los Diagramas de Comunicación de UML 2.0 son una versión simplificada de los Diagramas de Colaboración de UML 1.X, pero en la mayoría de los libros se refieren a estos como Diagramas de Colaboración, la idea es usar la versión 2.X o posteriores.

De que hay que usar la versión más reciente de los diagramas es seguro que muchos estaremos de acuerdo. El punto es que te has olvidado de que para hacer la debida transición de una versión a otra se ha propuesto, y se sugiere, distinguir al de Colaboración de Comunicación para que se vayan adaptando al cambio de semántica y no simplemente eliminarlo. ¿Versión simplificada? ¡Es casi directamente la misma cosa! Por ello he dicho: distinción semántica. Lo que pasa es que ahora al de Comunicación se lo ha hecho más light pero a su vez con más capacidad gracias a la gran cantidad de nuevas etiquetas y estereotipos. De allí que haya dicho que se trata de un Diagrama de Colaboración extendido. UML 2 vino con más cosas, a pesar de que se le ha hecho más light en algunos puntos.

Aunque tampoco es para matarse el de ir hacia 2.0+. UML 1.5 sigue siendo tanto o igual de útil que UML 2.0+ se puede hacer practicamente las mismas cosas, salvando algunos agregados. Y si con 1.5 te es suficiente, ¿Pues para que más?

Empezado por nlsgarcia

3- ¿Por que recomendar el libro "Aprendiendo UML en 24 Horas" y no otro más complejo?: El conocimiento se construye por capas y este libro permite una orientación inicial al tema y sirve de base para posteriores libros como por ejemplo "El Lenguaje Unificado de Modelado, Manual de Referencia" escrito por los autores de UML o cualquier otro que el lector decida, al final los libros son puntos de partida hasta que nos formemos un criterio propio, cada quien encoje con que libro iniciar el camino, la simplicidad es la base de la complejidad.

Que yo haya dicho que recomienda UML y Patrones o UML Gota a Gota no quiere decir que se lo lea de una sentada. Pero si considero que es mucho más valioso y enriquecedor que ir por textos más simples y cortos. Porque de una u otra forma ya debes migrar a algo más completo. Sugiero precisamente para no malgastar en tanto ir de un lado a otro directamente tomar a un material más completo. Creo que nadie se animará a darle una leída entera de una, es obvio que por más largo que sea uno lo hace de a poco, o a capas como dices.
Además existe una tendencia al "menos esfuerzo" en libros del tipo "Aprenda en x dias". Lo cual en términos académicos deja mucho que desear.

[[Delphius]]

Empezado por nlsgarcia

4- Con respecto a las Bibliotecas, Internet y la Red P2P Emule creo que pueden convivir perfectamente, al final es muy probable que todos los libros sean digitales y las bibliotecas virtuales sean la norma en lugar de la excepción por muchas razones que pienso son conocidas por las mayoría de las personas que usan una computadora asiduamente.

Habiendo el potencial de peligro con la ley SOPA y otras similares... ¿Aún así sugieres fomentar el acceso a una red de dudosa procedencia?
Llamenme clásico o anticuado pero prefiero tener un libro en mano que gastar más retina en leer en una pantalla. Es mucho más económico y saludable el pasar cada hoja con las manos, sentir el olor a cada hoja, y resulta más liberador y reconfortante... ha... y además no requiero estar prendiendo un aparatito para eso. Sólo gasta energía de mi cuerpo. Es transportable y puedo tener al alcance aún después de una tormenta solar
Que se gasta papel y talan árboles... no me vengan con eso. El problema no es que sea ecológico, como he dicho en una ocasión el problema es que luego los que talan no se toman la "molestia" de plantar nuevos.

Empezado por nlsgarcia

5- ¿El usar términos en ingles y en español en un mundo tan globalizado, signado por la tecnología y la internet dentro del ámbito de la computación es algo reprochable?, honestamente no lo creo pero respecto las opiniones contrarias.

No estoy en contra del inglés... sino de haber mezclado inglés y español. Si ya haz nombrado a la mayoría de los diagramas en español ¿que p*** necesidad hay de mencionar UNO en inglés? ¡Seamos coherentes!

Empezado por nlsgarcia

6- ¿Que si falto explicar esto o aquello sobre UML?, no es un tratado sobre UML es solo una orientación inicial a un problema real.

Mi exposición se debió a que creí que estabas hablando de DFD propiamente dicho y no de UML + estereotipo estructurado. Aunque aún así defiendo mis palabras y lo seguiré diciendo: ¡No mezclar!
Y francamente, por la forma en como lo encaraste, SI haz mezclado ambas cosas, y te has expuesto a que alguien te diera una buena aclaración.
Por ser un foro en donde no sólo existen profesionales sino estudiantes hay que ser lo más claros y académicamente responsables. Luego no es para nada deseable mezclar paradigmas y ni que decir... lenguajes visuales que son para paradigmas diferentes.
Si en verdad hubieras querido decir UML con estereotipos, ¡haberlo dicho!

Empezado por nlsgarcia

Pensamientos finales:

Creo que todo el problema se origino por una incorrecta redacción del punto uno el cual podemos reescribir como: "1- Es conveniente que empieces a modelar tu proyecto usando Casos de Uso de lo general a lo particular haciendo un paralelismo con los DFDs, (DFD-0) -> Caso General) y (DFD-1, DFD-2, ... , DFD-n) -> Casos particulares, pero tomando en cuenta que pertenecen a paradigmas diferentes y es válido solo como punto inicial del análisis."

Entonces admites que yo tuve en mi razón siempre y fue una falta tuya en no haberlo expuesto. Punto a mi favor.

Empezado por nlsgarcia

Otro punto de error fue no explicar mas extensamente los estereotipos en UML pero creo que la idea es dar una guía general en la mayoría de los casos que sirva de base a la solución del problema planteado en el post y recomendar otros links y libros que complementen la respuesta.

Tampoco es para dar clases de UML... no terminaríamos nunca. Si la idea es ofrecer una guía general, ¡con mucha más razón" evitar exponer lo de estereotipos... y mantener las cosas lo más limpia posible.

Empezado por nlsgarcia

Admito que la extensión de UML con estereotipos basados en DFD y DER es algo polémico y controversial para algunos,

¿Y no se te cruzó por la cabeza justamente evitarte todo eso y mantenerte en lo más simple y en todo caso hacer como acotación final que si desea ir por más estudiar estereotipos basados en DFD y DER?

Empezado por nlsgarcia

pero esto lo he probado en diversos ámbitos con resultados favorables a efectos de comunicación de nuevos conceptos y punto de partida de análisis mas detallados con los elementos propios del UML, esa es la idea detrás de todo este tema : Un punto inicial de transición del modelo estructurado al modelo OO por medio de UML.

Que haya sido tu experiencia es una cosa, puede que para otros sea distinta. Por ello es más sano separar la práctica de uno de la formación teórica básica y estándar. Fíjate porque yo precisamente sugerí el libro y no algo en particular como enfocarse en UML prototipado. UML y Patrones es una fuente muy cercana al área académica que le aportará un buen modo de ir tomando las cosas en capa y prepararse luego en como combinar diferentes herramientas... UML y Patrones combina el A/DOO, UML, Patrones de Diseño y los va presentando con el proceso UP. En sus primeros capítulos explica que si uno quiere ir por otro modelo de proceso puede hacerlo.
Luego el decidirá si ampliar y tomar su enseñanza por capas.
Tu error fue haber presentado el tema en base a tu experiencia como algo general. Y a mi me encanta señalar estas cosas: separar experiencia de uno de los conocimientos académicos para que luego uno revea como adquirir experiencia a su conveniencia.

Empezado por nlsgarcia

Para finalizar creo que debemos respetar las opiniones de todos, manifestar nuestro desacuerdo de forma profesional, educada y con argumentos y tratar de mantener un clima de cordialidad y ayuda a todas las personas que usen este medio, no creo que una discusión peyorativa y purista ayude en nada a resolver los problemas planteados en el Club Delphi, al final las personas que viene a este foro buscan soluciones practicas a problemas reales y no simple disertación teórica que aunque necesaria en su momento, no es el objetivo final.

Espero sea útil

Nelson.

Cuando vea un hilo que pida algo de práctica real y en donde lo deje bien en claro que no se trata de una deficiencia teórica me avisas para no dar mis sermones. No es la primera vez que David viene con una duda OO sobre diagramas... eso a mi ya me dijo que la raíz de su problema es una falta de una deficiencia teórica.
Hay hilos que requieren de dichas disertaciones. Como he dicho: en el foro hay gente profesional, hay estudiantes, hay autodidactas... si fueran todos los hilos con sólo sentido "real life" estoy seguro que muchos estudiantes y autodidactas se vienen abajo. Hay que condimentar a los hilos tanto de teoría como práctica... todos los hilos son igualmente de validez para todos por tanto hay que hacer los temas lo más abarcados y completos posibles para que se les pueda sacar el mayor provecho.
Sino vete a StackOverflow, que es todo real life y te evitas el mal sabor de que alguien te de una disertación teórica.

Saludos,

[[nlsgarcia]]

Delphius,

Nuevamente gracias por tus comentarios, creo que toda opinión es válida y da la oportunidad de aprender, mejorar y crecer profesionalmente.

Empezado por Delphius

Si en verdad hubieras querido decir UML con estereotipos, ¡haberlo dicho!

Esta comentado en el punto 2 de mi primera respuesta y explicado en mayor detalle en la segunda respuesta a tus comentarios.

Empezado por Delphius

Tampoco es para dar clases de UML... no terminaríamos nunca. Si la idea es ofrecer una guía general, ¡con mucha más razón" evitar exponer lo de estereotipos... y mantener las cosas lo más limpia posible.

La idea era dar una referencia teórica que permita establecer el paralelismo entre UML y el Análisis Estructurado basado en DFDs y DER, pero por supuesto depende del que lo lee investigar un poco sobre el tema, en este caso es un punto de partida práctico no la solución final y mucho menos ideal.

Empezado por Delphius

Que UML sea extensible es ya una cuestión secundaria, y por las circunstancias y su naturaleza.

Creo que es una gran virtud del lenguaje que expresa su gran capacidad de adaptabilidad y flexibilidad a diversos escenarios.

Empezado por Delphius

¿Y en donde yo he dicho que los Casos de Uso son extrictamente OO?

Solo explique el origen de los Casos de Uso y su relación con el A&D/OO, los Casos de Uso son fundamentales en UML y RUP y una herramienta muy poderosa para el modelado OO.

Empezado por Delphius

¿Versión simplificada? ¡Es casi directamente la misma cosa! Por ello he dicho: distinción semántica. Lo que pasa es que ahora al de Comunicación se lo ha hecho más light pero a su vez con más capacidad gracias a la gran cantidad de nuevas etiquetas y estereotipos

¿Podemos asumir que versión simplificada y se lo ha hecho más light son equivalentes?, si es así estamos de acuerdo.

Empezado por Delphius

Que se gasta papel y talan árboles... no me vengan con eso

Es tu opinión, la respecto pero no la comparto.

Empezado por Delphius

No estoy en contra del inglés... sino de haber mezclado inglés y español

Respeto tu opinión, pero no creo que sea la única.

Empezado por Delphius

Entonces admites que yo tuve en mi razón siempre y fue una falta tuya en no haberlo expuesto. Punto a mi favor.

No, pero agradezco tus comentarios.

Empezado por Delphius

¿Y no se te cruzó por la cabeza justamente evitarte todo eso y mantenerte en lo más simple y en todo caso hacer como acotación final que si desea ir por más estudiar estereotipos basados en DFD y DER?

No es posible, los estereotipos son fundamentales en la idea que quería plasmar.

Empezado por Delphius

Tu error fue haber presentado el tema en base a tu experiencia como algo general. Y a mi me encanta señalar estas cosas: separar experiencia de uno de los conocimientos académicos para que luego uno revea como adquirir experiencia a su conveniencia.

La vida esta basada en experiencias, la vida profesional no es la excepción, quizás con el tiempo hagas un postgrado y veras lo importante que son las experiencias personales propias y de terceros en el crecimiento académico y profesional, el tiempo lo dira.

Empezado por Delphius

No es la primera vez que David viene con una duda OO sobre diagramas... eso a mi ya me dijo que la raíz de su problema es una falta de una deficiencia teórica

Yo en lo personal no pienso que tenga derecho a juzgar los conocimiento de nadie en el Club Delphi, yo solo me limitare a ayudar en la medida que mis posibilidades lo permitan.

Empezado por Delphius

Sino vete a StackOverflow, que es todo real life y te evitas el mal sabor de que alguien te de una disertación teórica.

Al contrario, como ya he dicho anteriormente agradezco tus comentarios.

El respecto a las opiniones y sobre todo a las personas es fundamental, si simplemente decimos lo que pensamos por que consideramos que tenemos el derecho y no nos tomamos un momento en meditar sus consecuencias es muy probable que logremos el efecto contrario al deseado sin importar si tenemos la razón o no. La cordialidad, educación y profesionalismo no impiden que nuestros argumentos sean contundentes, al contrario los fortalecen.

Para finalizar creo que el objetivo fundamental de este foro es el conocimiento y la ayuda que podamos dar a las personas, eso y nada más.

Espero sea útil

Nelson

[Casimiro Notevi]

[off topic]

Empezado por Delphius

Habiendo el potencial de peligro con la ley SOPA y otras similares... ¿Aún así sugieres fomentar el acceso a una red de dudosa procedencia?

Hombre, Delphius, SOPA y P2P no tienen absolutamente nada que ver, el primero (que ahora lo han intentado "meter" con otro nombre y desde otros frentes) es un compendio de leyes para favorecer a una industria obsoleta y que se resiste a los nuevos tiempos, y que quiere seguir contando con unos privilegios de los que han disfrutado muchísimos decenios.
Lo segundo, como bien sabes, es un protocolo de comunicaciones con el que puedes poner a disposición de los demás tus archivos digitales (de cualquier tipo) para compartirlo con el resto del mundo.
Volvemos a lo de siempre, según tu teoría extrapolada a otros ámbitos, es como prohibir la venta de cuchillos de cocina porque pueden usarse para matar.
Mis documentos, informes, etc. los tengo compartidos en las redes P2P para quien quiera usarlos, yo lo llamo "compartir con los demás", ¿dónde está la dudosa procedencia?

Empezado por Delphius

Llamenme clásico o anticuado pero prefiero tener un libro en mano que gastar más retina en leer en una pantalla. Es mucho más económico y saludable el pasar cada hoja con las manos, sentir el olor a cada hoja, y resulta más liberador y reconfortante... ha... y además no requiero estar prendiendo un aparatito para eso. Sólo gasta energía de mi cuerpo. Es transportable y puedo tener al alcance aún después de una tormenta solar
Que se gasta papel y talan árboles... no me vengan con eso. El problema no es que sea ecológico, como he dicho en una ocasión el problema es que luego los que talan no se toman la "molestia" de plantar nuevos.

Cuando te acostumbras a un lector de libros electrónico... ¡¡¡ya no quieres libros en papel!!!, ¿sabes lo cómodo que es tener tu biblioteca completa (y mucho más) en un aparatito de escasos 200 gramos?, puedes usarlo en cualquier sitio con la ventaja de que no llevas un libro sino que puedes elegir el que más te apetezca en un momento dado.
Que conste que adoro mis libros en papel... que tengo intención de vender porque ocupan mucho espacio, pesan una barbaridad, se les acumula el polvo de años y la mayoría no los voy a volver a leer (y si quisiera leerlos sólo he de seleccionarlo en el "ereader").
Los libros de papel son un problema en las mudanzas y si te vas a una vivienda pequeña ya no tienes donde ponerlos.
Los libros en papel van a desaparecer, para bien o para mal, ya se venden muchos más "ebooks" que "libros" de papel.
Además son más baratos porque no llevan gasto de papel, impresión, manipulación, transporte, almacenaje, etc.
Que sí, que los libros en papel son más "románticos", pero también eran muy románticos los barcos con motores a vapor y... ¿dónde están?

[/off topic]

[roman]

Empezado por Casimiro Notevi

Cuando te acostumbras a un lector de libros electrónico... ¡¡¡ya no quieres libros en papel!!!

Aunque hay que aclarar que una cosa es un e-book y otra cosa es la pantalla de la computadora. No conozco yo mucho de eso pero he visto el kindle (sí, y sé que ese no te gusta ) y supongo que otros lectores son similares: no tienen nada que ver con la pantalla de una computadora.

1. No reflejan luz, que es lo que daña la vista. De hecho, no puedes leerlo en la oscuridad.
2. El gasto de energía es ínfimo.
3. No es "prender un aparato para leer", es abrir el libro; porque el encendido es instantáneo.

Supongo que Delphius desconce estas bondades.

Por otra parte, Dephius,

¿Es realmente necesario iniciar una polémica en todo momento?

Por otra parte, hay gente que para cuando ustedes terminar de leer el primer capítulo de UML, ellos ya están facturando al cliente

// Saludos

[Casimiro Notevi]

Empezado por roman

Por otra parte, hay gente que para cuando ustedes terminar de leer el primer capítulo de UML, ellos ya están facturando al cliente

Eso es seguro