Como podria modelar esto [Archivo]

david_uh

28-08-2012, 23:54:29

Hola foros de tiempo que entro al club la verdad extrañe este circulo tan activo, bueno a lo nuestro, pasa que estoy encargado de hacer un sistema de control de un colegio particular, y en esto estoy en la fase de modelado y creando mis clases, no tengo mucha practica en el análisis orientado a objetos y bueno tal vez esta pregunta les resulte tonta quizas pero me animo a hacerla a pesar de ello

En la institución tiene 3 niiveles inicial primaria y secundaria el alumno nuevo ya sea que entra a inicial o algún año por que sea que viene de otro colegio primero tiene que inscribirse y llenar una ficha de inscripción donde figuran sus datos, los datos de su madre y su padre, ahora después de esto es evaluado para ver si ingresa a la institución o no, si ingresa o aprueba los exámenes entonces se le matricula en el años escolar para lo cual se le toman datos y uno de los datos es apoderado, que es quien representa al alumno en la institución, y se elije de uno de los parientes del alumno padre o madre y otro pariente que haya registrado en la ficha de inscripción. hasta aquí yo he creado las siguientes clases:

Estudiante
----------
Codigo
Nombes
ApePat
...

Familiares
---------
Id
Nombres
....
parentezco

Apoderado
----------

teniendo esas tres clase yo me pregunto Apoderado seria una subclase de Familiares o una clase producto de la relación entre estudiante y familiares osea una clase de relación es decir graficándolo en uml

mi consulta seria estoy haciéndolo bien o que clases son las correctas o como debería ser modelado esto

Saludos

David

david_uh

31-08-2012, 05:59:03

Vaos foro algun aporte habra o solo son programadores??? animense a decir algo

champy

31-08-2012, 09:01:40

No comprendo demasiado bien la pregunta. Pero por lo que entiendo tienes dudas sobre como estructurar la base de datos en lo relativo al "Apoderado". ¿Es así?

Pues bien, si cada alumno va a tener varios parientes y solo uno de esos parientes va a ser apoderado entonces debería quedarte algo así.

Create table Alumnos (
ID_Alumno Integer not null, //Primary Key
Nombre Varchar,
Apellidos Varchar,
....)

Create table Familiares (
Id_familiar Integer not null, //Primary Key
FamiliarDe Integer not null, //F. Key
EsApoderador Boolean,
...)

Pero esto me da a pensar.... ¿contemplas la posibilidad de que un mismo familiar pueda ser apoderado a más de un alumno? en tal caso necesitarías de una tabla intermedia que una a Alumnos y Familiares para que tanto un alumno pueda tener varios familiares como que cada familiar pueda serlo de varios alumnos.

Create table Alumnos (
ID_Alumno Integer not null, //Primary Key
Nombre Varchar,
...)

Create table Familiares (
Id_familiar Integer not null, //Primary Key
Nombre Varchar,
...)

Create table RelacionEntreAlumnosYFamiliares(
Id_DelAlumno integer not null, //Primary Key
Id_DelFamiliar integer not null, //Primary Key
Parentesco Varchar,
Es_Apoderado Boolean)

Casimiro Notevi

31-08-2012, 09:58:21

mi consulta seria estoy haciéndolo bien o que clases son las correctas o como debería ser modelado esto

Es que no se entiende bien lo que preguntas.
Además de que eso no son clases, esos son campos de tablas de una base de datos.

Delphius

31-08-2012, 15:21:22

Vaos foro algun aporte habra o solo son programadores??? animense a decir algo
Aquí somos programadores que escriben código con Object Pascal, con una sintaxis exquisita y clara. Esto nos ayuda a que cuando explicamos hacemos buen uso de las reglas ortográficas, empleamos las comas, puntos y demás separadores ortográficos perfectamente.
Tu por otro lado pareces que vienes de C porque tu texto no se entiende nada. Al escribir te saltaste casi todos los signos. No se puede seguir el sentido de tus oraciones y por tanto, no se llega a comprender tus ideas.

Además, no hay obligación de responderte, y tan sólo han pasado 2 días. En el foro se tratan miles de preguntas por vez y puede que a alguien se le haya olvidado o no pudo darse más tiempo para aportar al hilo. Los demás también tiene sus obligaciones.
Si estás tan apresurado entonces ve a lo de otro colega por tu zona y le pagas los debidos honorarios para que haga el análisis por ti.

Hay varias maneras de pedir las cosas. Y evidentemente no elegiste la mejor opción.

Por otro lado si estás declarando clases, y ya que tu al parecer eres un gran programador y todo un excelente profesional debieras haber declarado esa clase de forma correcta. Para algo existe UML:

+-------------+
| NOmbreClase |
+-------------+
| Atributos |
+-------------+
| Métodos |
+-------------+

O hasta se te podría haber aceptado algo menos sofisticado:
NOmbreClase
-----------
Atributos
-----------
Métodos
-----------

E igualmente se te entendería.

Lo tuyo parece algo más orientado a la declaración de unas tablas para una base de datos (más que nada debido a que se vislumbra un atributo-Campo ID en la tabla-clase Familiares, que tiene sentido sólo en base de datos dicho sea de paso; y los nombres para las clases siempre van en singular) que la declaración de unas clases. Y si bien en UML se acepta el uso de estereotipos, y existe uno para las bases de datos casi todos los profesionales lo consideran aberrante, exagerado. Constantemente se hace el debido llamado a emplear el DER que es más apropiado para hablar sobre el contexto de una base de datos.

Cuando dices:
teniendo esas tres clase yo me pregunto Apoderado seria una subclase de Familiares o una clase producto de la relación entre estudiante y familiares osea una clase de relación es decir graficándolo en uml
Derrapas mal.
A ver, explícate, y ordena bien tus palabras... ¿Clase producto? ¿Clase de relación?
Cuando dices Clase, ¡te refieres exactamente a Clase según el paradigma OO, o más bién intentaste decir "tipo"?.
En la teoría OO/UML no existe el término "Clase de relación". Cuando dos clases se asocian entre si, y donde la cardinalidad puede leerse en ambos sentidos y existen atributos que podría ir en cualesquiera de ésta para formar la relación es que tenemos en el medio lo que se conoce como Clase Asociación y recibe los campos comunes y que permiten justamente romper con la ambigüedad. Y déjame decirte que posee una forma definida y contemplada en el estándar UML de representarla, como por ejemplo aquí (http://arodm.blogspot.com.ar/2008/09/uml-relaciones-compocicion-agregacion.html). En ese ejemplo puede verse con una línea punteada como se relaciona esta clase con las otras dos.

Creo que es eso a lo que intentaste referirte. Pero leyendo tus textos la verdad es que me pierdo.
A mi parecer al que le hace falta aprender algunas cosas es a ti.

Saludos,

david_uh

31-08-2012, 16:16:41

Buen día Foro

Gracias por sus aportes entiendo que no puse mucha información sobre mi pregunta por lo cual me disculpo, no fué mi intención molestar a nadie con mi segundo comentario y tengo muy en claro que nadie tiene la obligación de contestar mi pregunta, pero si, de alguna forma mis comentarios les resultaron inapropiados me disculpo por ello, siempre me he sentido bien en este foro por el alto nivel de actividad y colaboración que existe.

Continuando con la pregunta, la verdad es que no me refería a tablas, pero agradezco el aporte de champy me será de mucha utilidad mas adelante. Haciendo eco de las palabras de Casimiro Notevi aquí posteo mas información, en resumen el proceso es inscripcion evaluacion y si aprueba se procede a la matrícula describiéndose así:

PROCESO DE ALUMNOS NUEVOS

El apoderado llega a la institución solicitando informes, de acuerdo al nivel al que desea matricular a su apoderado se le entrega una ficha para que llene sus datos se le una fecha para una evaluación de conocimientos y psicológica, luego de lo cual se procede a una entrevista con la madre directora, después de eso se le da los resultados, en base a los resultados (obtenidos de las tres pruebas anteriores) se procede a efectuar la matrícula

PROCESO DE MATRICULA

Se procede a llenar una ficha de matrícula se le pide documentos (copia del dni del padre, la niña, carnet de vacunas, copia si es primaria o inicial) en caso de no tener DNI el menor se usa un código el cual es generado de la siguiente manera: año de nacimiento (02 dígitos)+código del colegio(inicial primaria secundaria)+nro de orden de matrícula, una vez hecho esto se procede a llenar sus datos, firma documentos, se le da documento de acreditación de alumna, se le informa de la fecha de inicio de labores, el proceso es el mismo para los tres niveles
Proceso de traslados externos
Normalmente se reciben hasta fines de septiembre, el proceso es similar al anterior

PROCESO DE CONTROL DE ASISTENCIA

El recojo de los partes de asistencia está a cargo de la encargada de normas educativas

Entonces el proceso de inscripción es uno y el de matrículas otro proceso separado, he aquí el diagrama de actividades de la Inscripción (http://delafuente.pe/imagenes/DiagActividadesIns.png)y de la matrícula (http://delafuente.pe/imagenes/DiagActividadesMat.png), y estas son las clases (http://delafuente.pe/imagenes/DiagClases.png) que he creado a partir de el enunciado. aún las clases no contemplan atributos.

Mis inquietudes serían ¿Que opinan de esas clases? ¿ están bien estructuradas? ¿alguna sugerencia? mi duda es con respecto a Familiar, Parentezco y Apoderado sobre todo, pudiendo el Estudiante tener como familiares a un padre, una madre, un tío, etc. pero solo uno de ellos es quien lo representa en la institución siendo este el Apoderado o quizás otro nombre vendría bien para esta figura.

No soy Experto en programación más bien diría un novato mucho más novato que caral todavía :D, y siempre cuando se me ha encargado algún proyecto siempre use mi propia terminología en diagramas y no UML sin embargo ahora tengo que hacerlo y debe ser Orientado a Objetos, por lo cual recurro a ustedes, agradecido de antemano por cualquier comentario me despidosde ustedes.

Saludos

David

Casimiro Notevi

31-08-2012, 16:49:09

Creo que ahora ha quedado más claro, a ver si algún experto te puede echar una mano, estas cosas yo las suelo hacer "a mano, y a mi manera" :)

Delphius

31-08-2012, 17:50:39

Bueno a ver, empecemos a hacer trizas ese diagrama de clases :rolleyes:

1) ¿Cuál es el objetivo de las clases Antiguo o Nuevo que descienden de Estudiante? ¿Tiene alguna utilidad o hay necesariamente un proceso específico que valga la pena destacar y separar en dos clases?
Esto te lo pregunto para que te hagas la pregunta si en verdad aporta o no alguna utilidad el tener esas dos clases. ¿No pensaste que tal vez te las podrías ahorrar y sería más apropiado disponer de un atributo que determine si es viejo o nuevo?

2) Algo parecido se puede hacer con toda esa rama de herencias que haces sobre el Personal. ¿De veras crees que es tan necesario abstraer a software todas las personas que te encuentras? ¿Que tiene de particular o de novedoso o interesante el que exista por ejemplo EncargadaSecretaria? ¿Cuál es el objetivo de cada clase? ¿Necesariamente todo el proceso que describes pasa por igualarlo y llevar a nivel software?

Por ejemplo, cuando lees que la directoria entrevista al alumno, ¿asumes que entonces es de interés llevarlo a software? Algo como:

var: DirectoriaRenegona: Directora;
begin
DirectoraRenegona.Entrevistar(AlumnoAsustado);
...
end;

Cuando se hace un diseño de las clases, no debe pensarse sólo en clases y empezar a meterlas como si nada. Debe cuidarse también si en verdad todas esas clases que estás metiendo te son de utilidad o están haciendo ruido. Además, parte del error está en no ir definiendo efectivamente que debe ir haciendo cada clase... Una combinación de los verdaderos procesos que son útiles y necesarios para llevar a cabo un verdadero control te dirá que vale poner o que vale sacar.

Eso no dice mucho si no te tomas el trabajo de poner mínimamente los atributos y métodos de interés.
Es como decir: venga, tengo todo esta cajas de productos, llenenmela... no se de que productos pero la quiero llena. O en tu caso: "tengo todas estas clases y no que se atributos y relaciones ponerles"

Eso lamentablemente no resulta. Si no puedes ver el contexto y tirar algo más integral, aunque sea borrador, va a ser difícil que podamos decir si va bien o mal. Y aquí debo hacer un debido llamado: en el mundo del análisis... ¡no hay dos iguales! Cada quien interpreta el contexto como considera apropiado. Por tanto no esperes LA respuesta.

Saludos,

Chris

31-08-2012, 19:25:05

roman

31-08-2012, 20:00:24

Casimiro Notevi

31-08-2012, 20:07:53

Yo no quería decir nada, pero es lo primero que hago, pienso en las pantallas, en los datos que se van a necesitar, cómo van a trabajar luego los usuarios con el programa, etc. y después diseño la base de datos con esa información :)

Delphius

31-08-2012, 21:05:32

El consejo que te daré es en resumen: Olvidá el modelado.

Dibuja la interfaz gráfica que tendrá tu aplicación. Muestra tus dibujos a las personas que usarán tu aplicación. Luego de las pruebas, si la interfaz es lo suficientemente buena para cumplir el propósito que necesitas, es hora de pasar al modelado.

Pero ojo! El modelado de los datos te los debe decir la interfaz gráfica, no al reverso.

El problema de iniciar el desarrollo de una nueva aplicación por el modelado, es que nunca sabrás las necesidades de la interfaz gráfica. Para el usuario la interfaz lo es todo. Les importa un carajo la estructura interna de la DB que soporta a esa interfaz.

Otro problema con iniciar con el modelado, es que trabajas en un espacio muy abstracto. Es por esa razón que te sientes confundido. Aunque lo dibujes, no te ayuda mucho a vislumbrar el resultado final, el punto B a dónde quieres llegar, que es un programa visualmente usable.

Si empiezas a trabajar por la interfaz, esto te dará una visión más amplia y lúcida del problema y cómo resolverlo.

Haz tus bosquejos de la interfaz. Muéstreselas a sus usuarios. Una vez aprobadas, vuelve acá y te podremos ayudar a realizar el modelo que soportará a la interfaz. Tómate tu tiempo.

Saludos!
:eek: Voy a hacer de cuenta que no dijiste nada :rolleyes:

Oye, Chris, por menos que esto, en cualquier bar de OOP purists ya te habrían apuñalado :D

Puñal, no... es poco. Yo siempre tengo a mano mi AK-47 :D

¿Cómo que empezar por la interfaz gráfica? Se supone que tu interfaz no debe guiar tu modelado y, de hecho, la interfaz tiene su propio modelado.

Por otra parte, muchas veces hago como tú :p :D

// Saludos
Es que el error está en los extremos... Se necesita vislumbrar las cosas desde al menos 4 puntos de vista: lógica, presentación, datos y la más difícil de todas: integral.
Si uno dedica su mayo esfuerzo en la presentación dejando de lado el aspecto lógico y el de datos muy seguramente tendrá una interfaces muy bonitas pero que por dentro será muy RAD, fuertemente basado en el uso data-ware y no tendrá demasiado sustento lógico. Luego cuando el sistema se necesite ampliar tendrá que ir toqueteando algo para que funcione.
Si uno se concentra en el aspecto lógico y deja de lado la presentación y los datos seguramente logrará tener un buen sistema capaz sostenerse a ciertos cambios en el contexto, pero llevarlos a visualizarlos y en cómo obtenerlos y pasarlos a la base de datos tendrá ciertas dificultades que le tocarán su operatoria. Generalmente este esquema conduce a una renuncia de data-ware.
Si uno se concentra en los datos seguramente tendrá una base de datos bien robusta, con muchas de sus operaciones optimizadas. Pero en cuanto a ciertas operatorias que escapan a las posibilidades de un motor debe ir al plano lógico y luchará por estabilizar a la lógica según el modelo de su base de datos.

En síntesis si intentas ir por cualquiera de estos caminos sin detenerte a analizar las repercusiones en los otros, seguro que en algo se cae y tendrás problemas. Lo que debe hacerse es cuando analizar por partes y cuando analizarlas de forma conjunta. Debe haber un equilibrio.

Saludos,

roman

31-08-2012, 21:25:33

Delphius

31-08-2012, 21:54:43

Yo de esto no sé. Realmente. Según recuerdo de cuando leí algunas cosas de Scott Ambler, una buena herramienta para iniciar una aplicación OOP son las CRC-Cards (http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card). El artículo de la wikipedia está muy chafa pero él lo describía mejor e indicaba que eran un medio muy bueno para hablar con los clientes.

Pues si, las tarjetas CRC son una de las opciones. Aunque hay que hacer la advertencia de que sólo son a modo de orientación o guía; aunque hay ciertos requisitos que dificilmente se pueden capturar en una tarjeta CRC. El problema de las tarjetas CRC está en que se condiciona a hablar en POO. Y hay ciertos clientes al que les cuesta entenderlas... El problema muchas veces está en que no se logra apreciar las clases. Es requisito fundamental contar con las clases para encarar las tarjetas.
Por este motivo se las suele complementar empleando los Casos de Usos, que logran capturar los procesos y luego de estas "historias" uno puede detectar las clases conceptuales y allí ya meterse con CRC.
Tanto CRC como los Casos de Usos son algunas de las técnicas empleadas para la recolección de requisitos... y aún así no todo se logra capturar o que sea fácil de asimilar. Por ello es que se adjuntan también los glosarios, tablas de especificaciones complementarias... incluso es hasta bueno o saludable tratar de entender el contexto analizando las visiones (como una lista de actores-objetivos).

Algo que tiene de bueno el enfoque de casos de uso es que ayuda a ordenar las cosas basándose en el contexto y los procesos. Para ello emplea una guía denominada Casos de Usos EBP (Elementary Business Processes). Es decir se resaltan las actividades y procesos más significativos y que aportan valor y significado al negocio, recolectando los datos que se necesita, quien lo hace, en que momento, y en respuesta a que evento.

De este modo ya el propio caso de uso te aporta y filtra el material para ir detectando las potenciales clases.

Tengo que contarte que las tarjetas CRC ya están quedando en desuso. ;)

Hay otros enfoques que fuerzan a detectar si las cosas las estamos pensando bien... el diseño dirigido por contratos ayuda a determinar que operaciones se necesita para ir de un estado consistente a otro. Cuando uno define las condiciones iniciales y finales ya puede darse una idea de como son las interacciones entre las clases, el estado y asignaciones de cada objeto.

En fin que no se trata de una única cosa... hay un enorme arsenal de herramientas que uno puede tomar. Y luego es que algunos dicen que la Ingeniería de Software es una burla :rolleyes:

Ya lo dijo Grady Booch:
Las personas son más importantes que cualquier proceso.
Buenas personas con un buen proceso siempre actuarán mejor que buenas personas sin procesos.

Saludos,
PD: No hace falta decir que soy defensor de la ingeniería de software supongo ;) :rolleyes:

Chris

31-08-2012, 23:50:44

Oye, Chris, por menos que esto, en cualquier bar de OOP purists ya te habrían apuñalado :D ¿Cómo que empezar por la interfaz gráfica? Se supone que tu interfaz no debe guiar tu modelado y, de hecho, la interfaz tiene su propio modelado.

Por otra parte, muchas veces hago como tú :p :D

// Saludos

Creo que david_uh, no se refería precisamente a la "TClass"... sino a la estructura de las tablas y la DB.

A los usuarios lo único que les importa es la interfaz. Les vale madre que su implementación sea un desastre o sea impecable. Por eso es que los usuarios prefieren Windows, a pesar de ser un desastre de S.O.

Un desarrollador o equipo experimentado puede crear una muy buena estructura interna usando la GUI como inspiración.

Cuando hacía aplicaciones para Delphi, lo primero que desarrollaba era el diseño de las ventanas. De hecho, esos diseños me sugerían una buena estructura para empezar. Por ejemplo, si la gran mayoría de ventanas requierían de un TDBGrid, entonces cuando hacía la implementación desarrollaba una clase, por ejemplo TDBModuleWnd. TDBModuleWnd ya incluía un TDBGrid y un TDataset con código centralizado para las operaciones CRUD y control de errores. Los herederos sólo cambiaban detalles.

Empezar con la GUI es trabajar de afuera hacía adentro. Empezar con los modelos es trabajar de dentro hacia afuera.

Si fueras a construir un edificio, primero vas con arquitecto para que te diseñe cómo se verá y esas cosas. Luego vas a un ingeniero civil para que haga los cálculos que soportarán ése diseño. Empezar con los cálculos primero es ir dando palmadas de ciego en el futuro. No sabes cuántos pisos tendrás, no sabes dónde habrán escaleras o no, dónde estarán las puertas, etc.

Saludos!

Casimiro Notevi

01-09-2012, 00:18:57

A los usuarios lo único que les importa es la interfaz. Les vale madre que su implementación sea un desastre o sea impecable.
Por eso es que los usuarios prefieren Windows, a pesar de ser un desastre de S.O.

Eso te va a traer cola :D

Aunque yo estoy de acuerdo :D:D:D

mamcx

01-09-2012, 00:20:06

Yo diria que ambas direcciones son necesarias. El problema de diseñar basado en la GUI es ampliamente documentado, y genera aplicaciones "acopladas", lo que en general es mala idea.

Por el contrario, sin tener un "destino final" es muy facil empezar a implementar codigo basura/inutil.

Lo que hago, luego de siempre hacer los diseños directamente en el IDE, luego tratar de usar UML, luego tratar de usar OO, luego de intentar usar especificaciones funcionales, luego de usar mockups, luego de usar unit testing, es esto:

- Usando un programa como www.pivotaltracker.com (cualquier cosa que soporte scrum, donde tenga: Estoy haciendo, hecho, por hacer) voy agregando que voy a hacer, que necesito, porque, los bugs, los errores, etc EN LA MEDIDA QUE NATURALMENTE VAN SALIENDO <= esto es lo importante, y en iteraciones de 1-2 semanas

- Hago mockups. Como quiero que salga la app al final

- Hago unit testing, que me va perfilando el API del sistema

-Uso un tablero para rayar, de esos blancos. O el iPad para hacer dibujos

- Cuando los unit test masomenos estan bien, voy montando la GUI. Refactorizo muy liberalmente.

- Repito todo lo anterior hasta que llegue a una version 1, en algun momento, miro los mockups iniciales y veo que algo que se me ocurrio no estaba en el sueño del producto, asi que lo descarto. Cuando me parece que me voy acercando, pongo un "fecha limite" de version 1, y lo que se me va ocurriendo lo pongo en la lista de "despues de version 1".

Es igual si la app es idea mia, o por medio de un cliente.

O sea, en general:

- Si veo que tratar de hacer un diagrama UML no me permite expresar bien lo que se necesita, o me entorpese el llegar a una solucion, desecho esa herramienta y cojo otra

- Si haciendo un unit test, comparado con el mockuo, veo que el unit test no expresa lo que busco, lo hago en la gui

- Si algo no esta en los requerimientos, y deberia, lo agrego

- Si algo no esta en los requerimientos, no lo hago. Y no, no es contradiccion con lo anterior

- Si hago un dibujo de la interfaz y eso no me resulve como hacer la tabla, hago la tabla en el motor de BD

- Si hago un tabla, y no veo como rayos eso tiene que ver con la GUI, pues miro la GUI, me doy cuenta que los datos los guardo de una manera que me va a resultar dificil guardar/leer esos datos despues, cambio la tabla. (intento que los datos expresen de forma natural, simple y directa lo que la APP necesita)

- Si el cambio en la tabla termina siendo un problema de desemepeño, ignoro un rato eso. Igual estoy cambiando todo todo el tiempo, ahora no es el mejor momento de resolverlo. Cuando lo es, se hace el refactoring (como dije, refactorizo de forma MUY liberal).

Le perdi el miedo a hacer cambios drasticos. En un sistema que estoy llegando a su version 1, luego de 3 meses, hemos hecho cambios drasticos como 3 veces, cambiado librerias fundamentales como 2 y si me toca hacerlo en un lenguaje diferente, pues lo hago.

PERO

Solo si esta dentro del alcance del proyecto, requerimientos, etc.

Osea, se usa la mejor herramienta para hacer el diseño de cada parte de la App. Una veces, es mejor directamente en codigo. Otras, directamente en la BD. Otras, es un mockup. Otras, es escribiendo. Otras es sentarse un rato y conversar con alguien sobre el tema.

El diseño lo trato como codigo, no duplico el esfuerzo innecesariamente (es por eso que no hago UML. Si el diagrama de clase sera una clase, la hago como una clase y listo. Para que duplicado en un UML y como codigo?)

"Use the source, Luke"

Delphius

01-09-2012, 03:06:57

Creo que david_uh, no se refería precisamente a la "TClass"... sino a la estructura de las tablas y la DB.

Entonces tenemos que darle un buen tirón de orejas para que llame a las cosas por su nombre.

A los usuarios lo único que les importa es la interfaz. Les vale madre que su implementación sea un desastre o sea impecable. Por eso es que los usuarios prefieren Windows, a pesar de ser un desastre de S.O.

Que la interfaz sea lo que en última ve el cliente/usuario no le da el mérito para rechazar los otros aspectos.
¿De que carajo sirve tener una hermosa fachada si por dentro las bases no son sólidas?
Ubuntu es según muchos de los GNU puristas y de lo más entendidos es la peor distro que hay (con el debido perdón Casimiro) ¡Y Oye, es Linux! Pero que bonito se ve.

Un desarrollador o equipo experimentado puede crear una muy buena estructura interna usando la GUI como inspiración.

Patrañas. Una estructura interna o para decirlo como debe: la lógica, o más técnico: las capa de aplicación y/o dominio (si nos vamos al OO) se analiza y se piensa para actuar independiente de cualquier ventanita. Y es lo deseable.
Si tomas como base las ventanas estás añadiendo dependencia, en mayor o menor grado, con la lógica. Lo cual no es bueno frente a procesos de mejoras y/o de reingeniería.

Cuando hacía aplicaciones para Delphi, lo primero que desarrollaba era el diseño de las ventanas.

Curioso, yo dejo la interfaz para lo último.

De hecho, esos diseños me sugerían una buena estructura para empezar.

Y creo que ya he señalado los peligros de seguir a rajatabla eso...

Por ejemplo, si la gran mayoría de ventanas requierían de un TDBGrid, entonces cuando hacía la implementación desarrollaba una clase, por ejemplo TDBModuleWnd. TDBModuleWnd ya incluía un TDBGrid y un TDataset con código centralizado para las operaciones CRUD y control de errores. Los herederos sólo cambiaban detalles.

¡Y aquí señoras y señores el mejor ejemplo! Una ventana acoplada no sólo a la lógica sino a las operaciones delgadas y abstractas de la capa de datos.

Empezar con la GUI es trabajar de afuera hacía adentro. Empezar con los modelos es trabajar de dentro hacia afuera.

Eso es precisamente lo que hace diferencia a un programador de un ingeniero. :D

Si fueras a construir un edificio, primero vas con arquitecto para que te diseñe cómo se verá y esas cosas. Luego vas a un ingeniero civil para que haga los cálculos que soportarán ése diseño. Empezar con los cálculos primero es ir dando palmadas de ciego en el futuro. No sabes cuántos pisos tendrás, no sabes dónde habrán escaleras o no, dónde estarán las puertas, etc.
Saludos!
¿Curioso no? Al que elabora los planos de los sistemas se los suele denominar arquitectos de software, o más formalmente analistas. Lo más curioso es que este análisis y los planos que elabora el analista es la primera etapa del trabajo que luego es enviada al programador para construya sobre él. :rolleyes:

Saludos,

david_uh

01-09-2012, 04:20:47

Creo yo que lo mas saludable informáticamente hablando es empezar por el modelado del sistema, el modelado es lo que a una arquitectura de un edificio se refiere teniendo un modelo claro coherente con clases bien definidas con atributos y metodos bien pensados es la columna vertebral de cada sistema informático, estoy en desacuerdo de empezar creando interfaces(aunque funciona bien para pequeños sistemas), aunque es algo que esta ya en tu cabeza, estas ya pensando como sería tal o cual pantalla, eso es innegable es como un instinto natural pero lo racional es que primero lo modelemos, es por ello que postee mis clases para saber cuales irian o cuales estan demás, ahora yo estoy seguro que el modelado y la definición de las clases no tien mucho que ver con la estructura de talas aunque claro los modelos son parecidos y es por ello que aparece JPA por la similitud que existe pero no quiere decir que las tablas sean el reflejo de nuestras clases. corríjanme si me equivoco.

Ahora volviendo a mis clases que cree, en el modelo de clases Estudiante, EstudianteNuevo, y EstudianteAntiguo tienen diferente trato pues el nuevo tiene primero que inscribirse ser evaluado, mientras que el antiguo pues ya tiene una pre-matricula y solo se apersona a la institución a matricularse con la seguridad de que su vacante esta separada y solo pagara y llenara algunos datos ya que el grueso de su información ya figura en los registros.mi problema era con lo de apoderado ya que siendo una persona que es familiar del alumno o no, podría ser una persona que haya sido autorizada por los padres, tal ve3z la clase Familiares no debería tener ese nombre sino mas bien Encargados o habria que crear una clase adicional llmada Parentezco como lo muestra el diagrama sin embargo que atributos o como seria alguna sugerencia, gracias por sus aportes.

saludos

David

Casimiro Notevi

01-09-2012, 10:01:34

Ubuntu es según muchos de los GNU puristas y de lo más entendidos es la peor distro que hay (con el debido perdón Casimiro) ¡Y Oye, es Linux! Pero que bonito se ve.
Sólo son envidias :)

roman

01-09-2012, 19:37:14

A decir verdad, salvo las críticas de fundamentalistas como noubuntu.org, que además van en otra dirección, nunca había escuchado eso de que es la peor distro.

// Saludos

Casimiro Notevi

01-09-2012, 20:57:37

Yo sí lo he oído/leído antes, pero lo decían porque permite instalar (si quieres) software no libre, principalmente los controladores gráficos.

Delphius

01-09-2012, 22:25:12

Sólo son envidias :)

Yo sí lo he oído/leído antes, pero lo decían porque permite instalar (si quieres) software no libre, principalmente los controladores gráficos.
Pues ese es uno de los puntos que yo también he leído. Y dicen que no sólo permite instalar software "no libre" sino que además, ¡ya viene con software no libre! Aunque eso no si es totalmente cierto.

He visto algo de esa web que comenta Roman, no se para que dirección apunta esa web pero no son los únicos que indican que Ubuntu es como la oveja negra de la familia GNU/Linux. Precisamente el principal defensor y creador del CopyLeft y el Software Libre (que no necesariamente el Open Source) NO APOYA A UBUNTU. De hecho según ÉL y la FSF, las siguientes distros (http://www.gnu.org/distros/common-distros.html) no son válidas. Las distros que si promueve son éstas (http://www.gnu.org/distros/free-distros.html). Que nos las conoce ni el.
Y la verdad es que no me explico esto cuando hace unos cuantos años reconoció que utiliza Debian (http://debian.barrapunto.com/article.pl?sid=01/09/09/1651240). ¿Que no era que no apoya a esta distro? ¿Que no era que utiliza Ututo?

Para ser un tipo que odia fanáticamente a lo no-libre... :rolleyes:

Saludos,

roman

01-09-2012, 22:35:33

Pedón, pero esto no tiene nada que ver con el funcionamiento de ubuntu. Se trata sólo de consideraciones algo fundamentalistas de porqué a la organización GNU le disgusta.

// Saludos

Casimiro Notevi

01-09-2012, 22:46:12

Sí, son motivos filosóficos, más bien. Por cierto, he comprobado qué software no libre tengo instalado y me ha salido esto:

antonio@linox:~$ vrms
Non-free packages installed on linox

lha lzh archiver
nvidia-current NVIDIA binary Xorg driver, kernel module and VDPAU lib
p7zip-rar non-free rar module for p7zip
rar Archiver for .rar files
unrar Unarchiver for .rar files (non-free version)
w32codecs win32 binary codecs

Contrib packages installed on linox

flashplugin-installer Adobe Flash Player plugin installer
flashplugin-nonfree Adobe Flash Player plugin installer (transitional pack
flashplugin-nonfree-extra Adobe Flash Player platform support library for Esound
gstreamer0.10-pitfdll GStreamer plugin for using MS Windows binary codecs
nvidia-common Find obsolete NVIDIA drivers
nvidia-settings Tool of configuring the NVIDIA graphics driver
ttf-mscorefonts-installer Installer for Microsoft TrueType core fonts
virtualbox-4.1 Oracle VM VirtualBox

6 non-free packages, 0.4% of 1620 installed packages.
8 contrib packages, 0.5% of 1620 installed packages.
antonio@linox:~$

Delphius

01-09-2012, 23:01:30

Pedón, pero esto no tiene nada que ver con el funcionamiento de ubuntu. Se trata sólo de consideraciones algo fundamentalistas de porqué a la organización GNU le disgusta.

// Saludos
Pucha... esto de copiar y pegar a las apresuradas que se olvidó pegar lo último que tenía en borrador.
Otras de las cosas que le reclaman es que utiliza partes de una versión kernel de Linux no libre. Y se comenta por los bajos mundos que parte de su código es un completo mamarracho y que muchas cosas no están bien pensadas o a medias. De allí que algunos le machacan a eso como las causas de ciertas incompatibilidades y problemas de una versión a otra.

EDITO:
¿Cómo es el comando a ejecutar Casimiro? ¿vrms? ¿Necesita de permisos root? Me interesa saber el porcentaje en mi máquina.

Saludos,

Casimiro Notevi

01-09-2012, 23:12:59

Pucha... esto de copiar y pegar a las apresuradas que se olvidó pegar lo último que tenía en borrador.
Otras de las cosas que le reclaman es que utiliza partes de una versión kernel de Linux no libre. Y se comenta por los bajos mundos que parte de su código es un completo mamarracho y que muchas cosas no están bien pensadas o a medias. De allí que algunos le machacan a eso como las causas de ciertas incompatibilidades y problemas de una versión a otra.

EDITO:
¿Cómo es el comando a ejecutar Casimiro? ¿vrms? ¿Necesita de permisos root? Me interesa saber el porcentaje en mi máquina.

Saludos,

Bueno, todo eso seguro que es mentira, el kernel es el mismo de debian, no igual, ni parecido, sino el mismo.

Sí, vrms, lo instalas normalmente y no hace falta permisos especiales ni nada para ejecutarlo.
sudo apt-get install vrms

Adivina a quién pertenecen esas iniciales rms :)

Delphius

01-09-2012, 23:43:13

Bueno, todo eso seguro que es mentira, el kernel es el mismo de debian, no igual, ni parecido, sino el mismo.

Tengo entendido que no es el mismo. Sino una ligera adaptación de él.
Toman como base al de Debian pero de allí en más se le hacen unos cambios.
En especial sobre lo que es detección de hadware ;) Muchas personas que han tenido problemas con Debian para que detecte sus equipos mágicamente con Ubuntu han podido sacarlo adelante. ¿Cómo es posible esto si en verdad fueran lo mismo? :rolleyes:

Ojo, no es que ataque a Ubuntu, ¡yo utilizo su hijo menor, Lubuntu! Nomás intento mostrar que por más ventanitas si algo por debajo anda mal... ¡es que seguro va a andar mal! :D A Ubuntu se lo conoce por tener problemas de una versión a otra cuando uno intenta actualizarlo (De hecho en mi flia hemos tenido unos problemas con el paso de la 11.10 a la 12.04 LTS en una de nuestras notebooks) . No es por nada pero es que ese argumento que expone en No-Ubuntu es verídico: tiene cierta tendencia a estallar, y esto lleva a que (quizá más por desconocimiento) uno reinstale para se arreglen los problemas.

Sí, vrms, lo instalas normalmente y no hace falta permisos especiales ni nada para ejecutarlo.
sudo apt-get install vrms

Adivina a quién pertenecen esas iniciales rms :)
ha... pensé que un comando, y no una aplicación que debía instalar.
Mejor no me recuerdes esas iniciales. :p

Saludos,