FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||||||
|
|||||||
Debate sobre UML y UP
Hola a todos, debido a que no quiero ensuciar más el tema tratado aquí, considero que es mejor continuar el debate fuera.
Me parece que por la forma en como se vino desarrollando, es mejor continuar la discusión en debates y no estar poniéndolo en POO. Con esto quiero dejar en claro que esto es ya un debate. Antes de comenzar, mis disculpas a rgstuamigo por no responderle antes. He tenido que partir de urgencia por motivo laborales y de negocios. Recién logro darme un tiempo, y no se hasta que punto pueda darme tiempo de hoy en adelante. Segundo, al tratarse de un debate me permito calzarme el apodo de gallego bruto, y voy a mantener mi postura mientras no considere que se me brinden fundamentos y fuentes más precisas para que pueda evaluar y entender en que punto y cuanto estoy equivocado. Espero no molestarlo pero considero que el tema merece mi total atención. Es como casi dirían... me juego el honor en esto Advierto que lo siguiente expresa mi humilde opinión. Espero que este sano debate sea enriquecido por muchos. Cita:
¡Y sigues diciendo que propone pasos! ¿Podrías decirme donde? No me vengas a decir ahora que indica que primero se hace un diagrama y luego otro porque allí si que me rio con una carcajada enorme. Cita:
Cita:
Pautas es totalmente diferente, y es más adecuada... pero quizá tampoco la mejor. UML no puede, ni debe entrometerse en ningún paradigma o modelo de desarrollo de ciclo de vida, la inversa también es válida. Sea Espiral, UP, etc. UML es una herramienta que uno puede o no optar por usar, ni le brinda pautas. Más adelante hablaré más de esto. UML ofrece "propuestas" que uno puede (re)considerar emplear para transmitir nuestras ideas. UML se limita al lenguaje visual. Y todas sus propuestas están dirigidas en ese punto. Que nuestras decisiones en el diseño visual en los diagramas nos lleve a interpretar y/o sacar conclusiones de como continuar con el proyecto eso es secundario... y escapa a UML. ¡Estamos ya en una re-interpretación del análisis! A lo que voy es que uno empleará los diagramas UML en cuanto uno lo considere útil. Uno no está, ni debería estarlo, obligado a emplear UML. Se puede concebir sistemas de calidad y sin haber empleado nada de UML; de poder se puede... difícil, pero se puede. Algo de UML se termina haciendo... al menos para refrezcar las ideas. Cita:
Claro que el cambio existe, no te lo discuto. Hay que actualizarse, cierto. En mi caso... a UML 2.0. No siempre se siguen los estándares. Se deberían seguir... no porque nos digan COMO, sino porque nos asisten y ayudan a elevar nuestra productividad, y nos permiten certificar que cumplimos con un marco de trabajo probado, evaluado. Hay estándares y estándares... Y voy a seguir insistiendo... ¡los estándares no dicen COMO! Dicen el QUE: QUE deberíamos ofrecer, QUE podríamos mejorar, etc. Muy cierto que algunos estándares y normas son muy quisquillosos... y establecen muy puntualmente que y que no... pero no te condicionan el proceso. ¡Tu dices el proceso! Si un estandar me dice que dice que debo hacer, ¿donde queda entonces el ingenio, la creatividad? Voy a dar y citar un ejemplo. En ISO 17799 se ofrecen recomendaciones, buenas prácticas... ¡pero no vas a encontrar el COMO! ¿Dime, vez un COMO en esto?: Cita:
Cita:
UP, o cualquier paradigma basado en las ideas UP, se "apoya" en UML para transmitir las ideas... De hecho organiza los diagramas en Modelos, y luego los modelos los engloba en uno o más disciplinas... pero no veo que UP imponga dichas clases. El objetivo es ofrecer un conjunto de diagramas que brinden una visión adecuada al concepto de sus disciplinas. Por ejemplo en la disciplina de Modelado del Negocio, UP arma o brinda el Modelo del Dominio, en el cual inserta un diagrama de clases a un nivel conceptual. ¿Porqué? Porque en la disciplina de Modelado del Negocio se pretende mostrar una visión global del ambiente... y confía en un diagrama de clases conceptual para transmitir el ambiente. ¿Me explico? Mantengo mi postura en que paradigmas de desarrollo de los ciclos de vida son independiente de UML y de las actividades reales que sigue uno. UP fue concebido inicialmente para enmarcar los proyectos y trabajos en un esquema que permita cierto dinamismo y actividades cíciclas para quienes seguían OO pero en ningún momento obliga a que debe emplear si o si OO en un UP. Por darte un ejemplo... puedo considerar que para un proyecto es viable un enfoque secuencial o algo más cascada y seguir un diseño OO. También nadie me impide usar un lenguaje estructurado con UP, quizá incluir en la disciplina de Diseño, dentro de su Modelo de Diseño mis cartas de estructuras, o en el Modelo del Dominio (disciplina de Modelado de Negocio), un diagrama de contexto. Fíjate que se sigue manteniendo la filosofía y propósito de cada disciplina. Se adaptó el Análisis Estructurado Moderno dentro de los modelos de las disciplinas que propone UP. Los ciclos de vida ofrecen un molde en el que uno encaja las actividades que se consideren oportunas en las actividades que propone dicho ciclo de vida. Nuestras actividades estructurales pueden, no necesariamente, alinearse y responder a algún estandar (como ser ISO 9001, 17799, etc) y se organizarán de modo tal que apoyados por el marco y filosofía de trabajo del paradigma optado nos conduza a un proceso organizado. Por ejemplo, el paradigma Espiral propone un esquema de trabajo cíciclo de menor a mayor. La idea central es que se va continuando con el trabajo en la medida en que los riesgos se van presentando. El trabajo se organiza por tanto enfrentandose a los requisitos y riesgos desde menos a más riegoso. Propone un período de actividad de evaluación en cada ciclo a fin de analizar si es viable dar otra vuelta más, ampliando el sistema o bien parar allí. En resumen, es defensivo, cauteloso... y es conveniente seguir este modelo cuando se trata de proyectos de ampliaciones y/o cuentan con fechas y plazos más o menos flexibles. UP es más agreviso: va directo a la "yugular", ataca a los riesgos potenciales y requisitos más inestables desde el principio a fin de estabilizarlos, en cada iteración re-planifica. ¿Dicen COMO? NO... Tal vez cuanto mucho un COMO sutil... más que nada proponen un modelo a seguir para nuestos proyectos. COMO vamos a poner en práctica al modelo, eso dependerá, en parte, de las actividades estructurales. Por poner un ejemplo, se considera que para esta ocasión es conveniente seguir actividades enfocadas más en estos puntos: AE1: estudio y análisis de la arquitectura AE2: rediseño de arquitectura AE3: control de cambios AE4: implementación de cambios AE5: pruebas formales AE6: documentación El Espiral típico, en cada ciclo, se basa en 6 actividades: A1: Comunicación con el cliente A2: Planificación A3: Análisis Riesgo A4: Ingeniería A5: Construcción y/o Adaptación A6: Evaluación del cliente Entonces, para cada Ax, aplicamos nuestras AE. Tenemos entonces un total de 36 macro actividades: A1: Comunic... A1.AE1: ... A1.AE6: ... ... A6: ... A6.AE6: ... Es decir que actividades estructurales (ese es el nombre académico que sugiere Pressman, yo las llamo actividades formales) se encuadran siguiendo el enfoque cíclico: nos cominicamos con el cliente (A1) sobre que opina de la arquitectura propuesta; ... analizamos el impacto de los riesgos (A3) de los altos cambios que llevamos en nuestras versiones (AE3 y AE4). Algunas tal vez sean pasadas por alto por carecer de sentido, otras consumirán tiempo... O quizá, decimos que antes de esas 36... mejor enmarcar en A1 la AE1, en A2 parte de AE1 y todo EA2, A3 no cuenta con una actividad formalmente establecida (se considera que puede llevarse un proceso liviano), etc. Y de este modo repartimos las AE a lo largo del ciclo del vida. Uno en base a su experiencia, tiempos, análisis, y otros factores que difícil podríamos llegar a enumerar totalmente armará un micro plan para esas macro actividades... Cita:
¡Madre santa! Que son esos círculos? ¿Me podrías brindar una fuente más completa sobre el tema? Al menos yo me tomé el tiempo y la libertad de darte a conocer mis fuentes, indica las tuyas. Bueno, ya me extendí demasiado. Saludos, Última edición por Delphius fecha: 19-04-2009 a las 08:36:46. |
#2
|
||||||||
|
||||||||
Hola Delphius ,me sorprende que hubieras abierto este hilo ya que mi intension no era debatir sino tratar de ayudar en lo que se pueda a algunos miembros del club.
En realidad el tema es bien amplio pero en mi caso solo quise hacer un resumen. Aclaro esto por que quisas se crea que yo soy experto en el tema;todo lo contrario, yo soy un simple aprendis que esta en este club compartiendo lo poco que sé y mucho mas recibiendo ayuda de parte de los demas miembros.Creo que tú mismo eres testigo de eso por que en mas de una ocasion me hechado una mano. Personalmente no me gusta llegar al extremo de algo pero dadas las circunstancias quiero postear algo complementario para que las dudas se pulan y se limen las asperesas. Cita:
No es que sigo diciendo que que propone pasos, sino dije que lo Ilustra.Es decir apunta a ello. Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Desde luego hay desventajas. Cita:
Bueno lo demas que toca es investigar por mi creo que es un tema de nunca acabar. Saludos...y Muchas Gracias...
__________________
"Pedid, y se os dará; buscad, y hallaréis; llamad, y se os abrirá." Mt.7:7
Última edición por rgstuamigo fecha: 20-04-2009 a las 23:07:34. |
#3
|
||||||||
|
||||||||
Cita:
Cita:
(1) Favor de no pensar cosas extrañas. Cita:
¿No te gusta llegar a extremo? Yo me siento genial haciendolo... dicen que hace daño ser extremista, donde uno debe elegir blanco o negro y rechaza las ideas de grises. No te aconsejo tratar de entenderme, soy bastante complicado y simple. Soy extremadamente volátil... De A hacia Z... zig-zag... Disculpa si te molesté y te ves demasiado envuelto en las palabras de NewDelphius.... tranqui... ya te acostumbrarás a él. Bueno vamos al grano. Cita:
Cita:
No es por llevar la contraria pero a mi modo de verlo e interpretarlo, UML no implica secuencialidad o pasos, ni lo ilustra. Si admito que uno mecánicamente, y en cierta forma intuitiva, realiza cierta secuencialidad cuando realiza sus diagramas y correcciones... pero lo considero como algo externo a UML: es producto del razonamiento de uno, no algo inmediatamente relacionado con la forma en como se trabaja con UML. Nuestro proceso o forma de trabajar es lo que nos indica la secuencialidad. Me cuesta aceptar la idea de que UML puede ilustrarlo puesto que uno puede optar o no por continuar "explotando" lo que el diagrama ofrece. Admito que ese párrafo estuvo de mas. Me disculpo. No es ni era mi entenciión hacerme ver en el hilo. Yo más bien quería manifestar de que no quisiera esperarme con algo así. Cita:
Distinto fuera si me dijeras que aplico a medias. Eso si te lo puedo aceptar. Lo que pretendí decir en dicho párrafo es que UML es muy amplio y la verdad es que considero que no todos los diagramas son necesarios. Uno realizará los diagramas que considere útiles, y por tanto aportan valor agregado, en su momento. No es por atacarte pero ¿acaso tu pones en práctica absolutamente todo lo que has leído? Disculpame por ser ignorante y no tan práctico. En la medida en que encuentro tiempo y ganas voy poniendo en práctica lo que estudio y aprendo. Hay mucho por estudiar y aprender... y priorizo lo que considero de mayor importancia y utilidad es para mi. Cita:
Cuando los auditores se presentan evalúan tus procesos (tus COMOS) y si cumples con los objetivos (el QUE) te certifican con que cumples con dichos objetivos. Pero en última no te dicen COMO debes llegar a dichos objetivos, estutos y/o normas. Ellos dicen QUE se debe cumplir, QUE no debería faltar, etc. Tu estableces una serie de procesos que cumplan con ese QUE... tu dices COMO. Si no cumples con sus puntos propuestos te señalan tus fallas o errores, pero no te diran COMO deberás corregirlos. No, me contradije en otro punto que señalaré más adelante (2).... Hay distintos significados de Calidad, y la gran mayoría, por no decir todos, son subjetivos, imprecisos. Hablar de calidad es... relativo. Tal vez el tener un certificado nos brinde cierta Calidad. Más el verdadero alcance de lo que puede ser la calidad está definida, guste o no, por alguien externo a nosotros. Si un cliente no se siente a gusto con algo, por más certificaciones que tengas, la calidad que le ofrecerás será baja. Espero que se entienda la idea. (2) Me contradije al decir QUE, debí decir COMO. A pesar de haber revisado mi lectura no me percaté del error. Pero de allí en más no veo contradicción. ¿Me podrías definir calidad? ¿La calidad se expresa únicamente por lo que digan los estándares? ¿Por emplear UML? ¿Donde comienza y termina la calidad? ¿Deberíamos hablar de calidad externa, interna, o de una sola? [IMG]file:///C:/DOCUME%7E1/ADMINI%7E1/CONFIG%7E1/Temp/moz-screenshot.jpg[/IMG] Cita:
Me resulta extraño... tu hablas de diagrama de colaboración pero en un link hablan de caso de uso y en el otro documento sobre despliegue. Me confunde eso... Lo que si noto es que si debemos seguir UML 2.0, al parecer el diagrama de colaboración de 1.5 lo debemos llamar diagrama de comunicación. Estuve leyendo referencias e interpreto discrepancias. En algunos sitios hablan de ex colaboración dando la idea de que ya no existe, y en otros se habla del diagrama de comunicación como una simplificación del diagrama colaboración, lo cual me lleva a interpretar de que sigue estando incorporado. El diagrama de colaboración sigue manteniendo su forma, al parecer... al menos en 1.5. Tengo que ponerme a ver este tema en profundidad. Saludos, |
#4
|
||||
|
||||
sobre uml.....
Hola para aportar algo al hilo........ quisiera decir que UML es un lenguaje de modelado..... como su nombre lo indica..... para que en posteriores ocasiones no se cofunda no es un paradigma de desarrollo de software.. como lo es rup por ejemplo..... pero vale decir que uml está orientado a objetos, es por esto que varios paradigmas de desarrollo emplean UML en el modelado del sistema.... o tal vez existan patrones de desarrollo (no son paradigmas sino pautas de desarrollo) como el libro de craig larman que menciona Delphius.
Ahora.....el desarrollo en capas es un paradigma de programación que depende del desarrollador el utilizarlo o no, aunque ultimamente está siendo adoptado con fuerza como es el caso de ruby on rails en el que sí o sí desarrollas en mvc. UML no fuerza a programar en capas...... es más... sólo se limita a describir el modelo de sistema.... de diferentes puntos de vista con los diferentes diagramas que presenta............. es por eso que no solo se lo utiliza en desarrollo de Software como se dijo anteriormente. En resumen: Modelado del Sistema -> Una parte del desarrollo de Software (UML es una herramienta que nos permite hacerlo) Paradigma de desarrollo -> Proceso de desarrollo de software que se compone de diferentes fases como requerimientos, analisis, diseño (en los que se modela el Sistema), implementación (puede ser mvc), pruebas....... dependiendo del paradigma... (rup, xp, espiral, estructurado...etc.) Saludos.
__________________
Soy pésimo en lo que mejor hago y por eso me siento bendecido. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Encuesta y debate sobre Articulos de patrones de diseño | Delphius | Debates | 8 | 10-06-2008 20:29:45 |
Articulo sobre la facilidad de probar componentes open source en windows sobre linux | gmontes | Noticias | 0 | 22-08-2007 22:34:16 |
Debate: Causas del fracaso de Kylix | rretamar | Debates | 22 | 13-03-2007 04:48:15 |
Debate de Inventarios | cmgenny | Debates | 2 | 14-05-2003 09:38:33 |
|