Desarrollo con UML

Abraham Snchez Lpez FCC/BUAP

(C) A. Snchez L. 2011

Introduccin
Presentar los principios de un soporte metodolgico. Proponer una metodologa sencilla de soporte al desarrollo con UML. p g p Ilustrar el inters de UML para el desarrollo.

(C) A. Snchez L. 2011

Anlisis y diseo
La finalidad de la actividad de desarrollo es proporcionar una solucin computacional a un problema planteado por un usuario (cliente). Tambin precisamos que el cdigo no era ms que la materializacin de la solucin, mientras que el modelo contena toda la informacin que facilitaba de una forma u otra la construccin de la solucin. Despus de esta introduccin a las vistas esenciales de un modelo UML (estructural, comportamental y funcional) de una aplicacin, nos queda por presentar la forma en que nosotros debemos utilizar cada una de estas partes con el fin de realizar nuestro objetivo: la realizacin de la solucin a partir del problema. Para lograr este objetivo, la ingeniera de software defini desde hace varios aos dos fases principales a realizar: p p el anlisis del problema y el diseo.

(C) A. Snchez L. 2011

Anlisis del problema, I p ,

La fase de anlisis sirve para modelar la comprensin del problema planteado por el cliente. Esta fase sirve tambin para definir bien los contornos de la aplicacin. Gracias a la fase de anlisis, sabemos lo que debe integrarse en la solucin, y tambin lo que no se debe puesto que la solucin slo debe tener en cuenta lo debe, que se defini en el anlisis. Idealmente, un anlisis debe ser realizado por el equipo de desarrollo y validado por el cliente es decir certifica que el equipo de desarrollo cliente, decir, comprendi bien su problema. En este curso, consideramos que el problema del cliente se especifica en un borrador de condiciones. El borrador de condiciones es un documento textual proporcionado por el cliente, pero que no se integra en el modelo de una aplicacin. p q g p En nuestro contexto, la fase de anlisis consiste en modelar todas las necesidades presentes en el borrador de condiciones.

(C) A. Snchez L. 2011

Anlisis del problema, II p ,

Un anlisis est completo cuando la integralidad del problema se modela de manera no ambigua. Para modelar un borrador de condiciones con UML, consideramos que solo dos partes del modelo UML son interesantes, las partes funcionales y estructurales:
La parte funcional permite especificar las funcionalidades realizadas por la aplicacin (caso de uso) as como los contornos de la aplicacin (actores). La parte estructural permite especificar en forma de objetos los datos que debe manipular la aplicacin. p p

Estas dos partes del modelo UML son suficientes para modelar las necesidades (requisitos) del cliente expresados en el borrador de condiciones condiciones. Sin embargo, con el fin de precisar bien los vnculos de coherencia entre estas dos partes, utilizamos tambin la parte comportamental, como nosotros lo mostramos anteriormente. i Esta parte permite en efecto vincular los casos de uso con las interacciones; estas mismas vinculadas a las clases.
(C) A. Snchez L. 2011 5

Anlisis del problema, III p ,

En el marco de nuestra visin esquemtica del modelo UML de una aplicacin, consideraremos que la fase de anlisis corresponde a un nivel de abstraccin que llamamos el nivel de requisito.

(C) A. Snchez L. 2011

Diseo de la solucin, I ,
La fase de diseo consiste en modelar una solucin que resuelve el problema modelado en la fase de anlisis. Contrariamente a lo que podramos creer, proporcionar una solucin computacional no es lo ms difcil: es solo un problema algortmico. Por el contrario es complicado proporcionar la mejor solucin al problema ya contrario, problema, que; a un problema dado, corresponden a menudo varias soluciones. Tomaremos el ejemplo del algoritmo de seleccin. Existen varias maneras de clasificar elementos (iterativa burbuja quicksort etc) (iterativa, burbuja, quicksort, etc). Todas estas soluciones resuelven el problema de seleccin desde un punto de vista algortmico, pero no son muy equivalentes, y sabemos muy bien que algunas son mejores que otras. Para diferenciar las soluciones, se conocen bien dos criterios: la complejidad en espacio y la complejidad en tiempo. p p j p Estos criterios permiten establecer una clasificacin de las soluciones en funcin de la cantidad de memoria que ocupan y del tiempo que realizan el tratamiento.
(C) A. Snchez L. 2011 7

Diseo de la solucin, II ,
Otros criterios, ms adaptados del mundo industrial y del paradigma orientado a objetos, permiten efectuar otras clasificaciones de las soluciones. Citamos, en particular, la capacidad de mantenimiento, la portabilidad, la robustez, la rapidez de desarrollo, el costo de desarrollo, etc. Esta lista no exhaustiva de criterios pone de manifiesto que la construccin de una solucin ptima dista mucho de ser trivial. Para ser ms pragmtico, y tambin para simplificar la dificultad de la fase de diseo, diseo consideramos en el marco de este curso que un diseo ptimo es un diseo que maximiza la independencia respecto a las plataformas tcnicas y minimiza la dependencias entre los distintos objetos de la aplicacin. Dado que el nivel conceptual permite definir un diseo independiente de las plataformas de ejecucin. Vimos por otro lado en los temas anteriores, que era posible minimizar las p q p relaciones de dependencia entre los paquetes del nivel fsico.

(C) A. Snchez L. 2011

Cmo pasar del q al cmo?, I p que ,

De manera intrnseca, el anlisis y el diseo son bsicamente diferentes, el primero corresponde a la modelizacin del problema, y el segundo a la modelizacin de la solucin. Existe entre estos dos niveles una relacin de resolucin, puesto que el diseo soluciona el anlisis. Es importante destacar que no se trata de una relacin de abstraccin tal como existe entre los niveles de abstraccin conceptual y fsico. La solucin (definida por el diseo) no es la concretizacin de un problema (definido por el anlisis) sobre una plataforma particular. Existe una verdadera diferencia entre el problema y la solucin. Es por otro lado donde el trabajo del desarrollador toma todo su sentido: proporcionar la mejor solucin susceptible de responder al problema. Sin embargo, el hecho de que el anlisis y el diseo aprovechen de forma g q p importante el paradigma orientado a objetos y que la solucin sea, por definicin, la solucin del problema vuelve un poco confusa esta diferencia q p que por lo tanto es fundamental.
(C) A. Snchez L. 2011 9

Cmo pasar del q al cmo?, II p que ,

El modelo de anlisis contiene clases, las cuales definen la estructura y el comportamiento de los objetos del problema. Con el fin de facilitar el paso de la fase de anlisis a la fase de concepcin, preconizamos identificar a nivel conceptual los grandes componentes de la aplicacin. p Cada componente desempea un papel especfico en la aplicacin, y el conjunto de los componentes es responsable de todas las funcionalidades de la aplicacin (expresadas en la fase de anlisis) anlisis). El recorte en componentes de una aplicacin es una operacin delicada, que permanece a cargo del desarrollador. Ah reside la relacin de resolucin entre el nivel anlisis y el nivel diseo. En el modelo UML de la aplicacin, los componentes se especifican a nivel conceptual. p

(C) A. Snchez L. 2011

10

Cmo pasar del q al cmo?, III p que ,

Cada componente se especifica por una parte funcional, que representa las funcionalidades del componente ofrecidas a su ambiente, una parte comportamental que representa ejemplos de realizacin de las funcionalidades del componente, y una parte estructural que representa las clases del componente. Adems, siempre a nivel conceptual, pero de manera transversa a todos los componentes, la parte estructural del modelo especifica las relaciones de dependencia entre los componentes. p p Estos se expresan bajo la forma de dependencia entre los paquetes que representan los componentes. UML no propone ningn concepto para especificar una relacin d i t ifi l i de resolucin entre los niveles requisitos y conceptual, preconizamos utilizar notas (comentarios) integradas en el nivel conceptual. Cada nota, vinculada a un elemento de cualquier tipo (clase, asociacin, objeto, mensaje, caso de uso, actor, etc.), debe identificar los elementos del nivel requisito especificando el problema en parte resuelto.
(C) A. Snchez L. 2011 11

Cmo pasar del q al cmo?, IV p que ,

Preconizamos precisar las relaciones de resolucin para cada componente del nivel conceptual. Ms concretamente, preconizamos, por una parte, ligar a los casos de uso de cada componente una nota dirigiendo los casos de uso del nivel requisito que el componente resuelve y, por otra parte, ligar a las clases o a los paquetes de p p p , g p q cada componente una nota dirigiendo las clases del nivel necesidad que el componente resuelve. La siguiente figura ilustra estas relaciones de resolucin entre el nivel requisito y el nivel conceptual. La figura evidencia dos grandes componentes en el nivel conceptual. Cada uno de estos grandes componentes se especifica con la ayuda de un diagrama de casos de uso, de un conjunto de diagramas de secuencia y de un diagrama de clases. Las relaciones de resolucin se esquematizan con ayuda de flechas entre los niveles requisito y conceptual.

(C) A. Snchez L. 2011

12

Relaciones de resolucin

(C) A. Snchez L. 2011

13

Resumen
Segn nuestra visin esquemtica del modelo UML de una aplicacin, consideraremos que: El anlisis corresponde a un nivel de abstraccin <<requisito>>. El diseo corresponde a dos niveles de abstraccin: el nivel conceptual y el nivel fsico fsico. El nivel conceptual especifica los distintos componentes de la aplicacin. El nivel fsico especifica la forma en que estos componentes se implementan en la l f l plataforma tcnica ( i (Java por ejemplo). j l ) Existe relaciones de resolucin entre el nivel requisito y el nivel conceptual. Estas relaciones se expresan con ayuda de comentarios en el nivel conceptual. Existe relaciones de abstraccin entre el nivel conceptual y el nivel fsico. Estas relaciones se expresan con ayuda de la relacin de abstraccin entre las clases. Gracias a estas relaciones entre todas las partes del modelo UML y las fases de anlisis y diseo, es posible completar nuestra visin esquemtica de un ciclo de desarrollo con UML como se ilustra a continuacin

(C) A. Snchez L. 2011

14

Ciclo de desarrollo con UML (completo) ( p )

(C) A. Snchez L. 2011

15

Mtodo de desarrollo, I ,
Sabemos que un mtodo de desarrollo debe responder a las siguientes preguntas:
Cundo realizar una actividad? Quin debe realizar una actividad? Q Qu hacer en una actividad? Cmo realizar una actividad?

Ahora que conocemos todas las partes del modelo UML de una aplicacin, sabemos lo que propone UML para responder a las preguntas del que y el cmo. Podemos por lo tanto proponer una respuesta relativamente minimalista a las preguntas d cuando y d l que, y as proponer un mtodo d d t de d del t d de desarrollo con ll UML. Nuestro objetivo consiste en terminar nuestra presentacin de UML presentando los principios bsicos de un mtodo de desarrollo. Nuestro mtodo no debe considerarse como un verdadero mtodo, aplicable en el medio industrial, sino ms bien como un mtodo pedaggico. , p g g
(C) A. Snchez L. 2011 16

Mtodo de desarrollo, II ,
Para responder a la pregunta del que, consideramos que existen esencialmente dos personas que participan en el desarrollo de una aplicacin. El cliente es la persona que tiene necesidad de la aplicacin, y el desarrollador es la persona que realiza la aplicacin. En el marco de este curso consideramos que el equipo de desarrollo slo est curso, formado por desarrolladores. Por lo tanto, la redaccin del borrador de condiciones, que especifica todos los requisitos, requisitos est a cargo del cliente y todas las actividades de desarrollo cliente, relativas al anlisis y al diseo estn a cargo del equipo de desarrollo. Para responder a la pregunta de cuando, consideramos que basta con proponer un orden de realizacin de cada una de las nueve partes del modelo UML. Hacemos la eleccin de proponer un orden a partir del borrador de condiciones y terminar con la produccin de la aplicacin final. p p As, nuestro mtodo que se limita a preconizar un recorrido en la realizacin de las partes del modelo, es un mtodo denominado top-down.

(C) A. Snchez L. 2011

17

Mtodo de desarrollo, III ,

Esto significa que slo es utilizable para la construccin de nuevas aplicaciones. Las ganancias de nuestro mtodo de desarrollo con UML son, como se podr destacar lo largo de este curso:
aprovechar las ventajas de las operaciones realizables sobre los modelos (generacin de documentacin, generacin de pruebas, definicin y correccin de las dependencias), aprovechar las ventajas de las operaciones realizables sobre el cdigo (redaccin del p j p g ( cdigo, compilacin y ejecucin), permitir un diseo independiente de las plataformas de ejecucin y minimizando las dependencias entre los componentes.

(C) A. Snchez L. 2011

18

El mtodo UML para el desarrollador, I p ,

Recapitulamos en esta seccin todas las etapas de nuestro mtodo de desarrollo con UML. Destacamos que las etapas 1 a 9 se refieren a la elaboracin de nueve partes del modelo UML. 0. Redaccin del borrador de condiciones: Objetivo: especificar todos los requisitos del cliente sobre la aplicacin. Cuando: C d esta etapa d b realizarse antes d empezar el d debe li de l desarrollo. No ll pertenece realmente pues al mtodo. Quin: el cliente. Qu: un documento textual donde se contabilizan todas las necesidades. Lo ideal sera poder definir cada una de las necesidades (requisitos) (dndoles un nmero, por ejemplo). Cmo: no preconizamos ninguna manera redactar un borrador de condiciones, esto queda fuera del contexto de este curso.

(C) A. Snchez L. 2011

19

Etapa 1 del desarrollo p

Anlisis (nivel requisito) - casos de uso: j p Objetivo: modelar las funcionalidades de la aplicacin y el ambiente de la aplicacin de manera no ambigua. Cuando: esta etapa es la primera de nuestro mtodo. Quin: el equipo de desarrollo desarrollo. Qu: el nico diagrama de casos de uso del nivel de abstraccin <<requisito>>. Cmo: con ayuda de una lectura cuidadosa del borrador de condiciones, es necesario, por un lado, definir las funcionalidades ofrecidas por la aplicacin con el fin de modelarlas bajo forma de casos de uso y, por otro lado, definir las entidades externas a la aplicacin que se benefician de las funcionalidades de la aplicacin con el fin de modelarlas bajo la forma de actores. Recordemos que no aconsejamos la utilizacin de relaciones de inclusin, extensin y herencia entre los casos de uso as como las relaciones de herencia entre actores.

(C) A. Snchez L. 2011

20

Etapa 2 del desarrollo p

Anlisis (nivel requisito) - interaccin: j j p Objetivo: modelar los ejemplos de realizacin de las funcionalidades de la aplicacin de manera no ambigua. Cuando: esta etapa debe realizarse despus de la etapa 1. Es posible realizar la etapa 3 al mismo tiempo que esta etapa Las clases de anlisis y el anlisis de etapa. interaccin pueden hacerse juntos. Quin: el equipo de desarrollo. Qu: Q un di diagrama d secuencia, por ejemplo nominal d realizacin d una de i j l i l de li i de funcionalidad y un diagrama de secuencia, por ejemplo de realizacin de una funcionalidad que se termine en error. Cmo: con ayuda de una lectura cuidadosa del borrador de condiciones, es necesario modelar ejemplos de realizacin de las funcionalidades. Aconsejamos reutilizar en la medida de lo posible los mismos objetos en las j p j distintas interacciones.

(C) A. Snchez L. 2011

21

Etapa 3 del desarrollo p

Con el fin de establecer un vnculo de coherencia entre las partes funcionales, comportamentales y estructurales, se aconseja caracterizar todos los objetos que participan en las interacciones, ya sea por actores (parte funcional), o por clases (parte estructural). Anlisis (nivel requisito) - clases: ( q ) Objetivo: modelar las clases que representan los datos especificados en el borrador de condiciones. Cuando: t t C d esta etapa d b realizarse d debe li despus d l etapa 1 y puede h de la t d hacerse al l mismo tiempo que la etapa 2. Las clases de anlisis clasifica y el anlisis de interaccin pueden hacerse juntos. Quin: el equipo de desarrollo. Qu: tantos diagramas de clases como sea necesario con el fin de facilitar la lectura de las clases as como sus relaciones. Cmo: con ayuda de una lectura cuidadosa del borrador de condiciones, es necesario modelar los datos especificados por el borrador de condiciones.

(C) A. Snchez L. 2011

22

Etapa 4 del desarrollo p

Aconsejamos no utilizar asociaciones navegables, ya que la informacin que podramos omitir (dependencias entre objetos) no incumbe a la fase de anlisis. Diseo (nivel conceptual) - casos de uso: Objetivo: modelar los componentes del diseo de la aplicacin. Cuando: esta etapa la cuarta de nuestro mtodo es la primera de diseo Debe etapa, mtodo, diseo. realizarse despus de todas las etapas de la fase de anlisis. Quin: el equipo de desarrollo. Qu: lista de los componentes y un diagrama de casos de uso por componente. Cmo: con ayuda de una lectura cuidadosa de todas las partes de la fase de a s s, anlisis, es necesario identificar los distintos componentes de la aplicacin, ecesa o de t ca os d st tos co po e tes a ap cac , luego elaborar el diagrama de casos de uso de cada uno de los componentes. Es necesario a continuacin especificar las relaciones de resolucin entre los diagramas de casos de uso de los componentes y el diagrama de casos de uso de la fase de anlisis.

(C) A. Snchez L. 2011

23

Etapa 5 del desarrollo p

Diseo (nivel conceptual) - interaccin: j j p Objetivo: modelar los ejemplos de realizacin de las funcionalidades de cada uno de los componentes de la aplicacin. Cuando: esta etapa es la segunda de la fase de diseo. Es posible realizar la etapa 7 al mismo tiempo que esta etapa etapa. Quin: el equipo de desarrollo. Qu: un diagrama de secuencia, por ejemplo un caso nominal de realizacin de una f i lid d Un di funcionalidad. diagrama d secuencia, por ejemplo d realizacin d de i j l de li i de una funcionalidad que genera un error. Cmo: a partir de la definicin de los componentes, es necesario elaborar ejemplos de realizacin de las funcionalidades que proponen. Aconsejamos reutilizar en la medida de lo posible los mismos objetos en las distintas interacciones. Con el fin de establecer un vnculo de coherencia entre las partes p funcionales, comportamentales y estructurales, se aconseja caracterizar todos los objetos que participan en las interacciones, ya sea por actores (parte funcional), o por clases (parte estructural). ), p (p )
(C) A. Snchez L. 2011 24

Etapa 6 del desarrollo p

Diseo (nivel conceptual) - clases: j p Objetivo: modelar las clases de los componentes. Todas las clases de un mismo componente deben pertenecer a un mismo paquete. Cuando: esta etapa, la tercera de diseo de nuestro mtodo, debe realizarse despus o al mismo tiempo que la etapa 5 5. Quin: el equipo de desarrollo. Qu: tantos diagramas de clases como sea necesario con el fin de facilitar la lectura d clases as como d sus relaciones. l de l de l i Cmo: a partir de la definicin de los componentes, es necesario modelar los datos que estos manipulan. Es necesario precisar las relaciones de dependencia entre las clases (intra componentes e inter componentes). Objetivo: modelar las clases de los componentes integrando las clases de la plataforma de ejecucin

(C) A. Snchez L. 2011

25

Etapas 7 y 8 del desarrollo p

Diseo (nivel fsico) - clases: p p Cuando: esta etapa es la primera de la fase de diseo del nivel fsico de nuestro mtodo. Quin: el equipo de desarrollo. Qu: tantos diagramas de clases como sea necesario con el fin de facilitar la lectura de clases as como de sus relaciones. Cmo: a partir de la especificacin de los componentes (parte estructural del nivel conceptual), es necesario d fi i l clases d l plataforma d ejecucin i l l) i definir las l de la l f de j i que permite la concretizacin de los componentes. Es necesario tambin integrar los tratamientos asociados a las operaciones en forma de nota de cdigo. Para terminar, es necesario precisar las relaciones de abstraccin con el nivel conceptual. Diseo (nivel fsico) - interaccin: ( ) Objetivo: modelar los casos de prueba abstractos. Cuando: esta etapa es la segunda de la fase de diseo del nivel fsico.

(C) A. Snchez L. 2011

26

Etapas 8 y 9 del desarrollo p

Cuando: esta etapa es la segunda de la fase de diseo del nivel fsico. Q Quin: el equipo de desarrollo. q p Qu: un diagrama de secuencia de prueba por caso de prueba abstracto. Cmo: para cada clase del nivel conceptual, es necesario definir varias pruebas abstractas que realizar y modelar estos casos de prueba con ayuda de los diagramas de secuencia de prueba. Nuestro mtodo no proporciona ningn medio para definir los buenos casos de prueba. Diseo ( i f i ) - casos de uso: i (nivel fsico) Objetivo: modelar las funcionalidades ofrecidas por los componentes, pero al nivel fsico. Cuando: esta etapa es la tercera de la fase de diseo del nivel fsico. Quin: el equipo de desarrollo. Qu: diagrama d caso d uso por paquete d l nivel f i Q un di de de t del i l fsico. Cmo: en principio, todos los componentes del nivel conceptual aparecen en el nivel fsico en forma de paquetes.
(C) A. Snchez L. 2011 27

Etapas 9, 10 y 11 del desarrollo p ,

Algunas funcionalidades de los componentes del nivel conceptual pueden no obstante ofrecerse directamente por la plataforma de ejecucin. La modelizacin de las funcionalidades a nivel fsico permite as diferenciar las funcionalidades directamente realizadas por la aplicacin de las ofrecidas por la plataforma. Generacin del cdigo y las pruebas: Objetivo: generar el cdigo de la aplicacin y el de las pruebas. Cuando: esta etapa es la primera de la fase de codificacin codificacin. Quin: el equipo de desarrollo. Qu: el cdigo de la aplicacin y el de las pruebas. Cmo: realizando las operaciones de generacin de cdigo y pruebas. Compilacin y ejecucin del cdigo y de las pruebas: Objetivo: compilar y ejecutar el cdigo d l aplicacin y el d l pruebas. Obj i il j l di de la li i l de las b Cuando: esta etapa es la segunda de la fase de codificacin. Quin: el equipo de desarrollo.
(C) A. Snchez L. 2011 28

Etapas 11 y 12 del desarrollo p

Qu: el ejecutable. j p p j p p Cmo: ejecutando las operaciones de compilacin y ejecucin proporcionadas por la plataforma de ejecucin. Modificacin de la aplicacin (correccin de errores o realizacin de evoluciones): Objetivo: actualizar la aplicacin. Cuando: en cualquier momento despus de la etapa 11. Quin: el equipo de desarrollo. Qu: modificacin del modelo o el cdigo. Cmo: modificando cualquier parte del modelo o modificando el cdigo Las cdigo. operaciones de generacin de cdigo e Ingeniera Inversa deben utilizarse para garantizar la sincronizacin entre el cdigo y el modelo. Todas t T d estas etapas, d t despus d l redaccin d l b de la d i del borrador d condiciones, se d de di i encuentran en nuestra visin esquemtica del modelo UML de una aplicacin, como se ilustra en la siguiente figura.
(C) A. Snchez L. 2011 29

Etapas del mtodo y p p partes del modelo UML

(C) A. Snchez L. 2011

30