Agradecería cualquier consejo para un nuevo equipo de desarrollo
que hemos creado en mi empresa y que es la primera vez que va a
utilizar use cases (aparte de recomendaciones de libros o sites
me gustaría saber si es posible algunos de los errores típicos
que comete la gente a la hora de enfrentarse por primera vez al
desarrollo guiado por use cases para así tratar de evitarlos).
Gracias anticipadas por vuestras aportaciones.

> que hemos creado en mi empresa y que es la primera vez que va a
> utilizar use cases (aparte de recomendaciones de libros o sites
> me gustaría saber si es posible algunos de los errores típicos
> que comete la gente a la hora de enfrentarse por primera vez al
> desarrollo guiado por use cases para así tratar de evitarlos).

Hace poco han sacado una serie de artículos en Software Development Magazine y recuerdo que había algunas referencias a errores comunes.

Echa un vistazo a: http://www.sdmagazine.com

Suerte :-)

El primer gran error es usarlos

> Invitado ha escrito:
> Agradecería cualquier consejo para un nuevo equipo de desarrollo
> que hemos creado en mi empresa y que es la primera vez que va a
> utilizar use cases (aparte de recomendaciones de libros o sites
> me gustaría saber si es posible algunos de los errores típicos
> que comete la gente a la hora de enfrentarse por primera vez al
> desarrollo guiado por use cases para así tratar de evitarlos).
> Gracias anticipadas por vuestras aportaciones.
>

> El primer gran error es usarlos

¿por qué? :-?

> Invitado ha escrito:
>> El primer gran error es usarlos
>
> ¿por qué? :-?

Describen una aproximación funcional,
qué hace el sistema y no cómo se comportan los
elementos del sistema

-Enfatizan el orden.
-Animan a un desarrollo funcional
-Confiar en un escenario significa
que hay un enfoque en cómo los usuarios
ven las operaciones del sistema
-DesembocaN en Top - Down

Como acertadamente cita Bertrand Meyer
(Object Oriented Software Construction, pg. 739):
"Except with a very experienced design team
(having built successful systems of several
thousand classes each in a pure O-O language),
do not rely on use cases as a tool for object
oriented analysis and design."

--JavierGP_0982

Invitado ha escrito:

>> > El primer gran error es usarlos

Hombre, me parece un poquito exagerado tomar como error su utilización :-D

> Describen una aproximación funcional,
> qué hace el sistema y no cómo se comportan los
> elementos del sistema

Desde luego no vas a basar el desarrollo de un proyecto exclusivamente en unos
casos de uso, pero no dejan de ser una herramienta útil (sobre todo si tienes
en mente el típico caso del comercial que vende un sistema que tiene que estar
para ayer pero que no sabe QUE debe hacer; bueno, también un poquito
exagerado, pero no creas que tanto :-D).

> Como acertadamente cita Bertrand Meyer
> (Object Oriented Software Construction, pg. 739):
> "Except with a very experienced design team
> (having built successful systems of several
> thousand classes each in a pure O-O language),
> do not rely on use cases as a tool for object
> oriented analysis and design."

Meyer es una referencia reconocida, pero sus opiniones me parecen igual
de buenas o malas que las de cualquier otro autor sobre estos temas (Larman,
Conallen, Fowler, ... o los mismos creadores de UML, en especial Jacobson);
puede haber ideas comunes y discrepancias (guiarse por los datos - OMT,
guiarse por casos de uso - UP, ICONIX, ..., ¿cuál es la mejor opción?,
yo sigo y seguiré teniendo mis miles de dudas, "cuanto más sé más es lo que
ignoro", pero con todo me sigue pareciendo útil el empleo de casos de uso),
pero hasta el punto de afirmar de los casos de uso que "El primer gran error
es usarlos"..., bueno, en cualquier caso la mía también es una opinión más :-)

Salu2 :-)

> javierml ha escrito:
> Invitado ha escrito:
>
>>> > El primer gran error es usarlos
>
> Hombre, me parece un poquito exagerado tomar como error su utilización :-D
>
>> Describen una aproximación funcional,
>> qué hace el sistema y no cómo se comportan los
>> elementos del sistema
>
> Desde luego no vas a basar el desarrollo de un proyecto exclusivamente en unos
> casos de uso, pero no dejan de ser una herramienta útil (sobre todo si tienes
> en mente el típico caso del comercial que vende un sistema que tiene que estar
> para ayer pero que no sabe QUE debe hacer; bueno, también un poquito
> exagerado, pero no creas que tanto :-D).

Los casos de uso nacieron como antesala a la extracción de clases. Más aún, es una
de las filosofías para dirigir una metodologías (junto con la responsabilidad y los datos). Por supuesto que no basarás el desarrollo sólo en casos de uso pero este comenzará por UC y comenzará mal. Recuerda como Objetctory e ICONIX hacen una extracción de clases a partir de UC, es decir, los UC fomentan una mala modularización del futuro sistema.

Si el sistema debe estar para ayer te aseguro que lo peor que puedes hacer es pararte a hacer UCs


>
>> Como acertadamente cita Bertrand Meyer
>> (Object Oriented Software Construction, pg. 739):
>> "Except with a very experienced design team
>> (having built successful systems of several
>> thousand classes each in a pure O-O language),
>> do not rely on use cases as a tool for object
>> oriented analysis and design."
>
> Meyer es una referencia reconocida, pero sus opiniones me parecen igual
> de buenas o malas que las de cualquier otro autor sobre estos temas (Larman,
> Conallen, Fowler, ... o los mismos creadores de UML, en especial Jacobson);
> puede haber ideas comunes y discrepancias (guiarse por los datos - OMT,
> guiarse por casos de uso - UP, ICONIX, ..., ¿cuál es la mejor opción?,
> yo sigo y seguiré teniendo mis miles de dudas, "cuanto más sé más es lo que
> ignoro", pero con todo me sigue pareciendo útil el empleo de casos de uso),
> pero hasta el punto de afirmar de los casos de uso que "El primer gran error
> es usarlos"..., bueno, en cualquier caso la mía también es una opinión más :-)
>
> Salu2 :-)
>

Siento discrepar en que las opiniones de Meyer sean comparables a las de Larman o a las Conallen, en mi humilde, particular y creo que ampliamente aceptada opinión me merecen más credibilidad las opiniones de Meyer que las de Larman (baste comparar sus obras). Respecto de Conallen sería extraño que hablase mal de los UC, todos sabemos de su afiliación a Rational. Con lo anterior me ahorro hablar de Jacobson, sus otros dos amigos y el pretendido monopolio metodológico - notacional (a la mejor usanza de Microsoft). Por último, y respecto a Fowler… ¿crees que en la actualidad es tan partidario de los UC?.

Tampoco quiero hacer un repaso de autores.

Los UC pueden ser útiles si… se restringe, limita y controla su uso, para proyectos no-OO y en proyectos lentos, sin riesgo y de excesiva documentación

Ante todo que impere el pragmatismo.

Ya para concluir me gustaría mentar que uno de los objetivos de esta crítica es, entre otros, recordar que la ingeniería del software, cómo ingeniería que es, debe estar más allá de las modas y debe en todo momento de corroborar el uso de cualquier nueva técnica o similar antes de recomendar indiscriminadamente su uso.

¿En qué proyectos triunfó Jacobson y sus UC?

Saludos

--JavierGP_0982

Invitado ha escrito:

> Los casos de uso nacieron como antesala a la extracción de clases. Más aún, es una

Bueno, ignoro el origen real, pero por lo que he podido leer son más antiguos
:-?, de los 60's y basados en algo llamado (si mal no recuerdo) "casos de
negocio" utilizados en Ericsson (de donde procedía Jacobson precisamente).

> responsabilidad y los datos). Por supuesto que no basarás el desarrollo sólo en casos
> de uso pero este comenzará por UC y comenzará mal. Recuerda como Objetctory e ICONIX
> hacen una extracción de clases a partir de UC, es decir, los UC fomentan una mala
> modularización del futuro sistema.

No acabo de ver el motivo de ese mal comienzo :-?. A tu entender entonces
¿cuál sería el primer paso a dar en un desarrollo OO ideal si damos por
sentado que no es bueno enfocarlo desde los UC?.

> Si el sistema debe estar para ayer te aseguro que lo peor que puedes
> hacer es pararte a hacer UCs

Entiendo que para proyectos de poca entidad, o símplemente adaptaciones de
otros o pequeños añadidos puede ser exagerado meterse con casos de uso (o con
diagramas de clases, o con simples DFD's clásicos o cualquier otra
"herramienta" sea para enfoque estático, dinámico o funcional), pero tiende a
generalizarse la idea de que cualquier proyecto es "de poca entidad" y
demasiadas veces nos encontramos con que nos plantean que todo lo que no sea
empezar a codificar desde ya mismo supone una pérdida de tiempo (no sería la
primera vez que se me dice algo como "es fácil, coges el proyecto A que fué
parecido, el B que tenía alguna semejanza y el C, y solo es copiar y pegar
código, o sea que para la fecha F listo").

El problema es que esto va ligado a ciclos de vida code&fix (por mi
experiencia demasiado frecuentes) con mayor o menor éxito en la elaboración
del producto, y con terribles quebraderos de cabeza en su mantenimiento y
posteriores ampliaciones tanto por parte del equipo de desarrollo original
como por quienes se van incorporando.

> Tampoco quiero hacer un repaso de autores.

La verdad es que no confío en lo que me diga un autor concreto :-D. Verás,
hasta hace alrededor de un año yo mismo no me había tenido que meter en serio
con un desarrollo orientado a objetos (uno ya es un poco "abuelete" :-D, pero
un buen día uno se encuentra con que hay que dar el salto de Yourdon y
similares y meterse con la OO, lo cierto es que bien o mal enfocado los
resultados han sido muy buenos), así que he tratado de ir documentándome
principalmente a base de leer libros de varios autores e ir extrayendo de cada
uno aquello que me parecía útil aplicar en mi situación, y la verdad es que a
mí particularmente me han sido útiles hasta cierto punto los diagramas de
clases y los casos de uso (no es la panacea pero mejor eso que nada).

En cualquier caso uno siempre está abierto a todo tipo de sugerencias, así que
por muy crítico que seas (en especial con los UC ;-D) tus comentarios en el
foro son bien recibidos :-)

Salu2 :-)

> javierml ha escrito:
> Invitado ha escrito:
>
>> Los casos de uso nacieron como antesala a la extracción de clases. Más aún, es una
>
> Bueno, ignoro el origen real, pero por lo que he podido leer son más antiguos
> :-?, de los 60's y basados en algo llamado (si mal no recuerdo) "casos de
> negocio" utilizados en Ericsson (de donde procedía Jacobson precisamente).
>
>> responsabilidad y los datos). Por supuesto que no basarás el desarrollo sólo en casos
>> de uso pero este comenzará por UC y comenzará mal. Recuerda como Objetctory e ICONIX
>> hacen una extracción de clases a partir de UC, es decir, los UC fomentan una mala
>> modularización del futuro sistema.
>
> No acabo de ver el motivo de ese mal comienzo :-?. A tu entender entonces

Yo jamás entendí como se pueden extraer clases
desde un UC

Otros motivos: todo lo que ya apunté en un mail anterior
y que desemboca por lo general en código NO OO

> ¿cuál sería el primer paso a dar en un desarrollo OO ideal si damos por
> sentado que no es bueno enfocarlo desde los UC?.

Depende del proyecto. En cualquier caso el uso de
CRC/RDD mucho más eficiente y rápido.

En entornos de riesgo el primer paso: ponerse a
hacerlo (con apoyo en una sesión rápida de CRC)


>
>> Si el sistema debe estar para ayer te aseguro que lo peor que puedes
>> hacer es pararte a hacer UCs
>
> Entiendo que para proyectos de poca entidad,

yo no diría proyectos de "poca entidad" más bien
diría "proyectos poco claros o de riesgo", es
decir, el 90% de los proyectos relacionados
con web, economía, etc. y que pueden ser
proyectos de mucha entidad

>o símplemente adaptaciones de
> otros o pequeños añadidos puede ser exagerado meterse con casos de uso (o con
> diagramas de clases, o con simples DFD's clásicos o cualquier otra
> "herramienta" sea para enfoque estático, dinámico o funcional), pero tiende a
> generalizarse la idea de que cualquier proyecto es "de poca entidad" y
> demasiadas veces nos encontramos con que nos plantean que todo lo que no sea
> empezar a codificar desde ya mismo supone una pérdida de tiempo (no sería la
> primera vez que se me dice algo como "es fácil, coges el proyecto A que fué
> parecido, el B que tenía alguna semejanza y el C, y solo es copiar y pegar
> código, o sea que para la fecha F listo").
>
> El problema es que esto va ligado a ciclos de vida code&fix (por mi
> experiencia demasiado frecuentes)

por la mia también

>con mayor o menor éxito en la elaboración
> del producto, y con terribles quebraderos de cabeza en su mantenimiento y
> posteriores ampliaciones tanto por parte del equipo de desarrollo original
> como por quienes se van incorporando.

Ya, pero ni "code and fix" ni Metrica o RUP, ni tanto
ni tan poco

>
>> Tampoco quiero hacer un repaso de autores.
>
> La verdad es que no confío en lo que me diga un autor concreto :-D. Verás,
> hasta hace alrededor de un año yo mismo no me había tenido que meter en serio
> con un desarrollo orientado a objetos (uno ya es un poco "abuelete" :-D, pero
> un buen día uno se encuentra con que hay que dar el salto de Yourdon y
> similares y meterse con la OO, lo cierto es que bien o mal enfocado los
> resultados han sido muy buenos), así que he tratado de ir documentándome
> principalmente a base de leer libros de varios autores e ir extrayendo de cada
> uno aquello que me parecía útil aplicar en mi situación, y la verdad es que a
> mí particularmente me han sido útiles hasta cierto punto los diagramas de
> clases

A mi también, claro que los Diagramas de Clases
bien entendidos, pequeños, como subconjunto software
y la mayoría de las veces para usar y tirar

>y los casos de uso (no es la panacea pero mejor eso que nada).

Estos si que no les he visto mucha utilidad,
siento diferir en que yo prefiero
nada a UCs

>
> En cualquier caso uno siempre está abierto a todo tipo de sugerencias,

gracias

>así que
> por muy crítico que seas

pragmático diría yo

>(en especial con los UC ;-D) tus comentarios en el
> foro son bien recibidos :-)

OK

Saludos

--JavierGP_0982

>
> Salu2 :-)
>

Invitado ha escrito:

> Yo jamás entendí como se pueden extraer clases
> desde un UC

Yo no me los planteo como un medio de extraer clases, quizá puedan dar alguna
idea para alguna situación concreta en ese sentido, pero los veo más como una
herramienta paralela para no perder de vista que debe hacer el sistema y para
"comunicarse" con el resto del equipo de desarrollo.

> Otros motivos: todo lo que ya apunté en un mail anterior
> y que desemboca por lo general en código NO OO

No te diré que no sea así, pero tampoco veo que los casos de uso deban ir
ligados necesariamente a una orientación a objetos, tanto puede desembocar en
código OO como no OO, aunque lo cierto es que gracias al hecho de meterlos en
el "paquete UML" parece que han sido etiquetados como exclusivamente OO; no me
parece que sea así realmente, a mí personalmente me parece que tienen su
utilidad en ambos enfoques (aunque no los veo muy adecuados precisamente para
extraer clases, y no creo que en Ericsson en los 60's desarrollaran OO pese a
sus "casos de negocio" :-D, así que aunque lo quieran hacer ver no me parece
que la orientación a objetos tenga el monopolio de los casos de uso).

Salu2 :-)