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. |
|
|
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 |
|