Debate sobre UML y UP

[[Delphius]]

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.

Empezado por rgstuamigo

Me parece que quisas estamos confundiendo algunos terminos,claro que por supuesto UML nos indica los pasos, estonces ¿para que fue creado?

UML fue creado para normalizar las diferencias entre las tantas propuestas de Modelado OO que surgieron y formalizar un modelo con el que se puedan comunicar ideas de una forma visual e independiente de cualquier lenguaje de programación, entorno, etc.

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

Empezado por rgstuamigo

para leerlo solamente y no aplicarlo.esto seria entonces una perdida de tiempo.

No es una pérdida de tiempo, es una herramienta valiosa. Cuando y donde usarla eso ya escapa al UML... lo decide uno, al menos así lo veo yo. Según lo considere necesario. Diagramitis es malo y eso si es perder tiempo.

Empezado por rgstuamigo

desde luego que UML no me va decir cada pasito asi detalladamente de lo que debo hacer en el proceso de creacion de algun software,como tu lo dices nos da todas las pautas,etc,sobre los cuales poder trabajar para hacer un software de calidad.

Te aclaro que eras tu quién inició y usó el término "paso".
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.

Empezado por rgstuamigo

Creo que en eso no estoy de acuerdo contigo,desde luego que la experiencia vale,pero no debes confiar todo en lo que as podido aprender,todo apunta a que vivimos en un mundo lleno de cambio y si se ha aprendido algo en el pasado,quisas en la actualidad sea necesario actualizarse, y aparte de eso siempre se sigue alguna norma o regla para fabricar cualquiercosa siguiendo los estandares.Y es exactamente en esto que nos ayuda UML.

Obvio que uno no se debe (o mejor dicho, debería) dejar llevar únicamente por su experiencia.
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?:

Empezado por Borrador ISO 17799

8.1.2 Control de cambios en las operaciones
Se deben controlar los cambios en los sistemas e instalaciones de procesamiento de información. El control inadecuado de estos cambios es una causa común de las fallas de seguridad y de sistemas.

Se deben implementar responsabilidades y procedimientos gerenciales formales para garantizar un control satifactorio de todos los cambios en el equipamiento, el software o los procedimientos. Los programas operativos deben estar sujetos a un control estricto de los cambios. Cuando se cambian los programas, se debe retener un registro de auditoría que contenga toda la información relevante.

Los cambios en el ambiente operativo pueden tener impacto en las aplicaciones. Siempre que sea factible, los procedimientos de control de cambios en las operaciones y aplicaciones deben estar integrados (ver también 10.5.1). En particular se deben considerar los siguientes ítems:

a) identificación y registro de cambios significativos
b) evaluación del posible impacto de dichos cambios.
c) procedimiento de aprobación formal de los cambios propuestos.
d) comunicación de detalles de cambios a todas las personas pertinentes.
e) procedimientos que identifican las responsabilidades por la cancelación de los cambios fallidos y la recuperación respecto de los mismos.

El seguir un estándar no implica, ni garantiza, que el resultado sea de buena calidad. Por empezar, calidad es una palabra con un significado bastante arraigado en la subjetividad... Yo puedo haber seguido UML al pie de la letra pero el sistema al final resulta ser una porquería. O la inversa, haber diseñado un sistema excelente y ni siquiera me tomé la libertad de hacer el diagrama de clases.

Empezado por rgstuamigo

En internet vas a pillar muchas referencias al respecto especialmente si se trabaja siguiendo el Proceso Unificado de Desarrollo(PUDS).

¿Que tiene que ver las clases control, interfaz e identidad con UP? No mezclemos manzanas con peras... decías que eso se usa en UML, ahora me dices UP... ¿al final?

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

Empezado por rgstuamigo

Puede ser que talves tú al Diagrama de colaboracion lo has trabajado de una forma standar,pero si lo trabajaras aplicado al desarrollo de software los cuadrito o red que tu lo llamas deben ser mas especificos.
quisas te ilustre esta imagen:
http://www.cuelgalo.com/viewer.php?i...8_Ejemplo1.JPG
Saludos....

Y ahora me dices que yo sigo el estandar... ¿entonces tu no lo sigues? ¿Aplicado a que? ¿Más específicos? ¿Podrías ser más claro?

¡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,

[rgstuamigo]

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.

Empezado por Delphius

UML fue creado para normalizar las diferencias entre las tantas propuestas de Modelado OO que surgieron y formalizar un modelo con el que se puedan comunicar ideas de una forma visual e independiente de cualquier lenguaje de programación, entorno, etc.

Esa definicion se la puede encontrar en cualquier libro. y creo que eso ya lo sabemos.

Empezado por Delphius

¡Y sigues diciendo que propone pasos!
¿Podrías decirme donde?

No es que sigo diciendo que que propone pasos, sino dije que lo Ilustra.Es decir apunta a ello.

Empezado por Delphius

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.

No saques conclusiones solo para verte bien en el hilo.

Empezado por Delphius

No es una pérdida de tiempo, es una herramienta valiosa. Cuando y donde usarla eso ya escapa al UML... lo decide uno, al menos así lo veo yo. Según lo considere necesario. Diagramitis es malo y eso si es perder tiempo.

Eso te postie por que tú mismo en el otro hilo decias que muchas veces leias un libro pero que no aplicabas lo que aprendias.

Empezado por Delphius

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?:

Claro que hay un como sino chequea este link (esto es en la norma ISO 9000)especialmente en el proceso de certificacion,Ahi dice que si una empresa quiere ser certificada deben someterse a una auditoria, entre otras cosas, y aparte dice que si el auditor encuentra incumplimiento,la organización tiene un plazo para adoptar medidas correctivas.Esto quiere decir que la empresa debe seguir algunas normas para la certificacion,lo cual va contrario a lo que estas diciendo:

Empezado por Delphius

Si un estandar me dice que dice que debo hacer, ¿donde queda entonces el ingenio, la creatividad?

No crees que tu mismo te estas contradiciendo?

Empezado por Delphius

El seguir un estándar no implica, ni garantiza, que el resultado sea de buena calidad.

Todo lo contrario dice aqui:

Su implantación en estas organizaciones, aunque supone un duro trabajo, ofrece una gran cantidad de ventajas para las empresas.
Los principales beneficios son:

• Mejorar la satisfacción del cliente
• Mejorar continuamente los procesos relacionados con la Calidad.

Otros beneficios adicionales son:

• Reducción de rechazos e incidencias en la producción o prestación del servicio
• Aumento de la productividad

Esto generamente sucede para cualquier norma ISO.
Desde luego hay desventajas.

Empezado por Delphius

¡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 para no hacerla muy larga aqui y aqui te pongo algunos link para que veas como se hace un diagrama de colaboracion con esos círculos que tu llamas.
Bueno lo demas que toca es investigar por mi creo que es un tema de nunca acabar.
Saludos...y Muchas Gracias...

[[Delphius]]

Empezado por rgstuamigo

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.

Yo tampoco, pero igual que tu considero que yo también podría ayudar en algo. Y este debate ayuda: refrescamos nuestra memoria y de paso sirve para que otros se sumen (me agradaría que así lo hicieran, sino esto se convertiría en dialogo).

Empezado por rgstuamigo

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.

Yo tampoco soy un experto, y aún así me arriesgo. Si buscas en los foros hallarás muchos hilos en los que no era bueno entrometerme... y bueno... que se le va a hacer... a veces uno entre donde no le llaman. Digamos que soy medio masoquista (1).

(1) Favor de no pensar cosas extrañas.

Empezado por rgstuamigo

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.

No tengo problemas en que te expreses.. hace bien, todos aprendemos de todo.
¿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.

Empezado por rgstuamigo

Esa definicion se la puede encontrar en cualquier libro. y creo que eso ya lo sabemos.

Bueno, si... es que como me lo preguntaste, y yo contesté. Hubiera sido mejor preguntar en todo caso: ¿A qué quieres llegar con "para que fue creado?"?

Empezado por rgstuamigo

No es que sigo diciendo que que propone pasos, sino dije que lo Ilustra.Es decir apunta a ello.

Es que no has dicho ilustra en ningún momento, y seguías empleando la palabra pasos.

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.

Empezado por rgstuamigo

No saques conclusiones solo para verte bien en el hilo.

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

Empezado por rgstuamigo

Eso te postie por que tú mismo en el otro hilo decias que muchas veces leias un libro pero que no aplicabas lo que aprendias.

Aplicar o no aplicar es muy binario, ... y extremista. Puedo aceptarte tus palabras si me das una prueba concreta de que no pongo en práctica absolutamente nada de lo que leo.
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.

Empezado por rgstuamigo

Claro que hay un como sino chequea este link (esto es en la norma ISO 9000)especialmente en el proceso de certificacion,Ahi dice que si una empresa quiere ser certificada deben someterse a una auditoria, entre otras cosas, y aparte dice que si el auditor encuentra incumplimiento,la organización tiene un plazo para adoptar medidas correctivas.Esto quiere decir que la empresa debe seguir algunas normas para la certificacion,lo cual va contrario a lo que estas diciendo:

Lo siento pero debo decir que estás errado. Las normas te indican y te "obligan" a cumplir con una serie de objetivos. Más está en uno en definir COMO alcanzar esos objetivos.
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.

Empezado por rgstuamigo

No crees que tu mismo te estas contradiciendo?

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]

Empezado por rgstuamigo

Bueno para no hacerla muy larga aqui y aqui te pongo algunos link para que veas como se hace un diagrama de colaboracion con esos círculos que tu llamas.
Bueno lo demas que toca es investigar por mi creo que es un tema de nunca acabar.
Saludos...y Muchas Gracias...

Gracias por las referencias.
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,

[2-D@monic]

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.