Está en la página 1de 122

Trabajo de Investigacin

DLSARROLLO DL UNA ML1ODOLOGA PARA


UN NULVO PARADIGMA DL DLSARROLLO DL
SOI1WARL





LLNGUAJLS Y SIS1LMAS INIORM1ICOS
DLPAR1AMLN1O DL INIORM1ICA

Autor: Daniel lLRNNDLZ LANVIN
Director: Aquilino Adolo JUAN lULN1L
Junio 2004








1bere are tro ra,. of cov.trvctivg a .oftrare ae.igv:
Ove ra, i. to va/e it .o .ivte tbat tbere are
obriov.t, vo aeficievcie.
ava tbe otber ra, i. to va/e it .o covticatea tbat tbere are vo obriov. aeficievcie..
C. .. R. oare













a abvta aet Caaaor ae Dragove.

...e cvevta ae vv ;orev cbivo qve aeaic toaa .v riaa a arevaer et arte ae caar aragove.,
ba.ta qve e.tvro .egvro qve ,a aovivaba toaa. ta. tecvica. ae cvo caar aragove..
v e.e vovevto .e aio cvevta qve vo babav ev et vvvao aragove. qve vaierav .er caaao.
, et ;orev .e aeaic a ev.evar cvo caar aragove....

Tabla de Contenidos
CAP1ULO I IN1RODUCCIN........................................................................................................ J
CAP1ULO II PARADIGMA DL PROGRAMACIN ORILN1ADA A CONJUN1OS............ 3
CAP1ULO III NO1ACIONLS Y LLNGUAJLS DL MODLLADO............................................. 9
CAP1ULO IV ML1ODOLOGAS DL DLSARROLLO.............................................................. 30
CAP1ULO V IAMILIAS ML1ODOLGICAS .......................................................................... 47
CAP1ULO VI HLRRAMILN1AS CASL...................................................................................... 97
CAP1ULO VII LNLAS DL INVLS1IGACIN..........................................................................J02
CAP1ULO VIII GLOSARIO........................................................................................................J08
CAP1ULO IX RLILRLNCIAS.....................................................................................................JJ0
Tabla de Contenidos
CAP1ULO I IN1RODUCCIN........................................................................................................ J
1.1 ORGANIZACIN DLL DOCUMLN1O................................................................................................................. 1
CAP1ULO II PARADIGMA DL PROGRAMACIN ORILN1ADA A CONJUN1OS............ 3
2.1 PROGRAMACIN ORILN1ADA A CONJUN1OS................................................................................................ 3
2.2 LL LLNGUAJL VLNN........................................................................................................................................... 3
2.2.1 a 1iificaciv ae aato. ev 1evv .................................................................................................................
2.2.2 1ratavievto ae to. vetoao............................................................................................................................. :
2.2. .ritvetica ae cov;vvto. .................................................................................................................................
2.2.1 1ratavievto ae Covteto. .............................................................................................................................
2.3 ADLCUACIN DL LAS ML1ODOLOGAS OO A LA POC................................................................................ 8
CAP1ULO III NO1ACIONLS Y LLNGUAJLS DL MODLLADO............................................. 9
3.1 ALCANCL DL LOS LLNGUAJLS DL MODLLADO.............................................................................................. 9
.1.1 Moaeto. e.tatico. o ae e.trvctvra .................................................................................................................. 10
.1.2 Moaeto. aivavico. o ae covortavievto ...................................................................................................... 11
3.2 LL LLNGUAJL DL MODLLADO UNIlICADO ,UML, ................................................................................... 11
.2.1 Diagrava. |M....................................................................................................................................... 12
,i, Diagramas estaticos o de estructura.........................................................................................................................13
,ii, Diagramas dinamicos o de comportamiento .........................................................................................................20
.2.2 Carevcia. aet |M.................................................................................................................................... 2
CAP1ULO IV ML1ODOLOGAS DL DLSARROLLO.............................................................. 30
4.1 AN1LCLDLN1LS lIS1RICOS \ LVOLUCIN.............................................................................................. 30
4.2 DLlINICIN \ CONCLP1OS............................................................................................................................. 30
1.2.1 Metoao. ae vgeviera aet .oftrare ............................................................................................................... 1
1.2.2 erravievta. .............................................................................................................................................. 2
1.2. Metoaotoga. o roce.o. ae ae.arrotto............................................................................................................ 2
4.3 MODLLOS DL PROCLSO.................................................................................................................................... 34
1..1 Moaeto Cta.ico o ev Ca.caaa ...................................................................................................................... :
1..2 De.arrotto rotvtiro o Prototiaao..............................................................................................................
1.. v .irat .................................................................................................................................................
1..1 De.arrotto vcrevevtat ................................................................................................................................
1..: De.arrotto orvat ae .i.teva......................................................................................................................
1.. Coaificar , Corregir.....................................................................................................................................
1.. Moaeto. ae Proce.o briao. .......................................................................................................................
4.4 ALCANCL............................................................................................................................................................. 40
1.1.1 .ctiriaaae. 1ecvica. o ae ae.arrotto. ........................................................................................................... 10
,i, Obtencin de los requisitos. ......................................................................................................................................41
,ii, Analisis...........................................................................................................................................................................42
,iii, Diseno del sistema.......................................................................................................................................................42
,i, Diseno detallado ..........................................................................................................................................................42
,, Implementacin ...........................................................................................................................................................42
,i, Pruebas...........................................................................................................................................................................42
1.1.2 .ctiriaaae. ae aavivi.traciv , ge.tiv aet roce.o ae ae.arrotto .................................................................. 1
,i, Comunicacin...............................................................................................................................................................43
,ii, Administracin de la undamentacin.....................................................................................................................43
,iii, Administracin de eolucin del sotware. ............................................................................................................44
,i, Administracin del proyecto .....................................................................................................................................44
,, Control del ciclo de ida del sotware .....................................................................................................................44
4.5 CLASIlICACIN.................................................................................................................................................. 44
1.:.1 Cta.ificaciv ev ba.e a .v agitiaaa ............................................................................................................... 1:
,i, Metodologas de Ingeniera o burocraticas.............................................................................................................45
,ii, Metodologas giles. ...................................................................................................................................................45
1.:.2 Cta.ificaciv ev ba.e a .v atcavce................................................................................................................. 1:
1.:. Cta.ificaciv ev ba.e a ta vatvratea aet ro,ecto......................................................................................... 1
CAP1ULO V IAMILIAS ML1ODOLGICAS .......................................................................... 47
5.1 ML1ODOLOGAS ORILN1ADAS A lLUJO DL INlORMACIN..................................................................... 4
:.1.1 Metoaotoga ae .vati.i. .trvctvraao , Metoaotoga ae ai.evo ae Yovraov ................................................ 1
,i, Introduccin.................................................................................................................................................................4
,ii, Modelo de proceso......................................................................................................................................................51
,iii, Actiidades del ciclo de desarrollo...........................................................................................................................51
5.2 ML1ODOLOGAS ORILN1ADAS A DA1OS ...................................................................................................... 54
:.2.1 rotvciv.................................................................................................................................................... :1
:.2.2 t Metoao ae ]ac/.ov................................................................................................................................. :1
,i, Introduccin.................................................................................................................................................................54
,ii, Modelo de proceso......................................................................................................................................................55
,iii, Actiidades del ciclo de desarrollo...........................................................................................................................56
5.3 ML1ODOLOGAS ORILN1ADAS A OBJL1OS................................................................................................... 61
:..1 t Proce.o |vificaao ae ae.arrotto ae .oftrare ;R|P) ................................................................................ 1
,i, Introduccin.................................................................................................................................................................61
,ii, Modelo de proceso......................................................................................................................................................62
,iii, Actiidades del ciclo de desarrollo...........................................................................................................................64
5.4 ML1ODOLOGAS BASADAS LN ROLLS........................................................................................................... 9
:.1.1 Moaetaao ae ta reatiaaa cov Rote................................................................................................................
:.1.2 a vetoaotoga OOR.M ;Ob;ect Orievtea Rote .vat,.i. ava Moaettivg) ................................................ 0
,i, Introduccin.................................................................................................................................................................80
,ii, Modelo de proceso......................................................................................................................................................82
,iii, Actiidades del ciclo de desarrollo...........................................................................................................................82
,i, Consideraciones ...........................................................................................................................................................84
5.5 ML1ODOLOGAS GILLS DL DLSARROLLO .................................................................................................. 86
:.:.1 e`treve Progavvivg ..................................................................................................................................
,i, Introduccin.................................................................................................................................................................8
,ii, Modelo de proceso......................................................................................................................................................8
,iii, Las practicas propuestas por XP..............................................................................................................................88
,i, Consideraciones ...........................................................................................................................................................91
5.6 ML1ODOLOGAS DL DOMINIO LSPLClICO.................................................................................................. 92
5. ML1ODOLOGAS lIBRIDAS............................................................................................................................. 94
:..1 a vetoaotoga M1RC. ................................................................................................................... 1
,i, Introduccin.................................................................................................................................................................94
,ii, Modelo de proceso......................................................................................................................................................94
,iii, Actiidades del ciclo de desarrollo...........................................................................................................................95
:..2 .ctiriaaae. ae aavivi.traciv , ge.tiv aet roce.o ae ae.arrotto ..................................................................
CAP1ULO VI HLRRAMILN1AS CASL...................................................................................... 97
6.1 IN1RODUCCIN................................................................................................................................................. 9
.1.1 Orgeve. ......................................................................................................................................................
6.2 1LCNOLOGA CASL......................................................................................................................................... 9
6.3 CLASIlICACIN.................................................................................................................................................. 98
..1 erravievta. |er Ca.e ..........................................................................................................................
..2 erravievta. Miaate Ca.e .........................................................................................................................
.. erravievta. orer Ca.e...........................................................................................................................
..1 erravievta. ae ivgeviera ivrer.a ..............................................................................................................
..: erravievta. ae ivgeviera ae iaa , rvetta................................................................................................. 100
.. erravievta. ae avbito e.ecfico.............................................................................................................. 100
6.4 lLRRAMILN1AS CASL ORILN1ADAS A OBJL1OS...................................................................................... 100
CAP1ULO VII LNLAS DL INVLS1IGACIN..........................................................................J02
.1 AGILIZACIN DL ML1ODOLOGAS CLSICAS............................................................................................. 102
.2 AU1OMA1IZACIN DL PROCLSOS DL DLSARROLLO................................................................................. 103
.3 MODLLADO DL SIS1LMAS BASADOS LN CONJUN1OS................................................................................ 104
.4 ML1ODOS DL DLSARROLLO DL SIS1LMAS BASADOS LN CONJUN1OS.................................................... 105
.5 IN1LGRACIN CON lLRRAMILN1AS CASL,IDLS................................................................................... 105
.6 lORMALIZACIN DL RLQUISI1OS MLDIAN1L LGICA DL PRLDICADOS. ............................................. 106
. CONCLUSIONLS................................................................................................................................................ 10
CAP1ULO VIII GLOSARIO........................................................................................................J08
8.1 DLlINICIONLS ................................................................................................................................................. 108
.1.1 Reqvi.ito................................................................................................................................................... 10
.1.2 1area ........................................................................................................................................................ 10
.1. Recvr.o ..................................................................................................................................................... 10
.1.1 .ctiriaaa o a.e....................................................................................................................................... 10
.1.: ^otaciv................................................................................................................................................... 10
.1. evgva;e ae Moaetaao............................................................................................................................... 10
.1. Paqvete ..................................................................................................................................................... 10
.1. Metoaotoga ae .vati.i. ............................................................................................................................ 10
.1. Metoaotoga ae avbito e.ecfico ................................................................................................................ 10
.1.10 evgva;e ae ro.ito e.ecfico.................................................................................................................. 10
CAP1ULO IX RLILRLNCIAS.....................................................................................................JJ0

Tabla de Ilustraciones
ligura 1 Ljemplo de Conjuntos en POC......................................................................................................................... 5
ligura 2 1ratamiento de sobrecarga de mtodos en POO...........................................................................................
ligura 3 1ratamiento de contextos en POC...................................................................................................................
ligura 4 Diagramas en UML 2.0 ..................................................................................................................................... 13
ligura 5 Ljemplo de Diagrama Lstatico de Clases ...................................................................................................... 14
ligura 6 Ljemplo de diagrama de componentes .......................................................................................................... 15
ligura Ljemplo de diagrama de estructuras compuestas......................................................................................... 16
ligura 8 Ljemplo de diagrama de despliegue................................................................................................................ 1
ligura 9 Ljemplo de diagrama de paquetes................................................................................................................... 20
ligura 10Ljemplo de diagrama de casos de uso........................................................................................................... 20
ligura 11 Ljemplo de diagrama de estados ................................................................................................................... 22
ligura 12 Ljemplo de diagrama de actiidad ................................................................................................................ 23
ligura 13 Ljemplo de diagrama de interaccin............................................................................................................. 25
ligura 14 Ljemplo de diagrama de colaboracin ......................................................................................................... 26
ligura 15 Ljemplo de diagrama de isualizacin de interaccin ............................................................................... 2
ligura 16 Ljemplo de cronograma.................................................................................................................................. 28
ligura 1 Modelo clasico en cascada.............................................................................................................................. 35
ligura 18 Desarrollo eolutio........................................................................................................................................ 36
ligura 19 Desarrollo en espiral........................................................................................................................................ 38
ligura 20 Notacin del DlD........................................................................................................................................... 49
ligura 21 Notacin extendida del DlD........................................................................................................................ 50
ligura 22 Lstructuras de control ..................................................................................................................................... 5
ligura 23 Conexiones de Jackson ................................................................................................................................... 58
ligura 24 Lstructura de datos .......................................................................................................................................... 60
ligura 25 Modelo de proceso RUP ................................................................................................................................ 63
ligura 26 lases del modelo de proceso RUP ............................................................................................................... 64
ligura 2 Abstraccin de rol ............................................................................................................................................ 9
ligura 28 Ljemplo OORAM ........................................................................................................................................... 83
ligura 29 Modelo de proceso XP ................................................................................................................................... 8
ligura 30 Coste del cambio en metodologas clasicas ................................................................................................. 88
ligura 31 Coste del cambio en metodologas agiles..................................................................................................... 88
ligura 32 Procesos y actiidades cubiertas por ML1RICA 3.................................................................................... 95
ligura 33 Proceso DSI ML1RICA 3 ............................................................................................................................. 96
ligura 34 Arquitectura Model Drien Architecture................................................................................................... 104
ligura 35 Representacin de clase s conjunto.......................................................................................................... 105
ligura 36 lormalizacin de requisitos.......................................................................................................................... 10
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 1
CAPTULO I INTRODUCCIN
Lste trabajo de inestigacin pretende realizar un estudio sobre las metodologas de
desarrollo de sotware existentes. Se analizaran las metodologas mas representatias dentro
de cada amilia, sus elementos dierenciadores, sus puntos uertes y sus inconenientes, su
aplicabilidad a proyectos reales y, como medida de su eectiidad, la diusin que han
alcanzado en cuanto a aplicacin real en el sector priado del desarrollo de sotware.
Desde que en 1968 y como consecuencia de la conerencia de la O1AN apareciera
en escena el concepto de Ingeniera del Sotware` |NAUR69|, el desarrollo de los
programas an entonces concebidos como complemento al hardware -pieza mas costosa e
importante- comenz a tomarse mas en serio. Los pequenos proyectos hasta entonces
desarrollados comenzaban a crecer en complejidad y tamano. Ll coste del mantenimiento
de los programas se disparaba, debido a lo cual el oco de atencin comenz a centrarse en
el desarrollo de ste sotware. La consecuente adopcin de los mtodos tradicionalmente
aplicados a los procesos de ingeniera clasica, propici la aparicin de las distintas
metodologas que hoy en da se emplean ,o se han empleado, para desarrollar grandes
sistemas de inormacin.
La toma de requisitos, la organizacin del equipo de desarrollo, la generacin y
mantenimiento de documentacin acerca del producto o la planiicacin de los procesos de
desarrollo son slo algunos de los aspectos de los que el coordinador de un proyecto de
sotware tiene que preocuparse si pretende llear a buen puerto el desarrollo del producto.
loy en da es habitual encontrarse equipos de desarrollo ormados por mas de einte
personas, o proyectos inmensos que se diiden en pequenos subproyectos, siendo an mas
importante las labores de organizacin y coordinacin de la construccin del producto. Ls
por tanto necesario aplicar una serie de reglas, emplear un lenguaje comn y compartir una
disciplina de trabajo que permita conocer en cada momento en estado real del proceso de
construccin del sotware, de orma que un proyecto no se transorme en una aentura a
ciegas en la que el equipo se lanza a generar lneas de cdigo contra reloj.
Bajo este prisma, a lo largo de la corta historia de la inormatica, y segn iban
apareciendo nueas posibilidades tecnolgicas y paradigmas, se han ido creando nueas
metodologas que, o bien adaptaban los mtodos ya probados y consolidados, o bien
incorporaban nueas tcnicas innoadoras para cubrir determinadas actiidades del
proceso de desarrollo. La deinicin de un nueo paradigma requiere entonces un proceso
de adaptacin de aquellos elementos ,notaciones, lenguajes de modelado, mtodos, etc.,
que no se prestan al desarrollo de sotware con las nueas caractersticas que aporte. Lstas
actualizaciones o adaptaciones suelen determinar un punto de relexin y mejora de lo ya
presente, siendo justiicacin habitual para la adopcin y,o descarte de mtodos cuando
existan alternatias interesantes ya probadas y consolidadas.
1.1 ORGANIZACIN DEL DOCUMENTO
Lste documento presenta la siguiente estructura organizada en captulos y
apartados:
A lo largo del captulo II se realiza una presentacin general del paradigma POC
,Programacin Orientada a Conjuntos,, la lnea de inestigacin actual del grupo OO1LAB
|OO1LAB| que trata de eolucionar la orientacin a objetos, aportando nueas
caractersticas que requieren ser tratadas durante los procesos de desarrollo sotware.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 2
Ln el captulo III se analizan los lenguajes de modelado, dialecto obligado en
cualquier metodologa de desarrollo basada en representaciones graicas, centrando la
atencin en el UML, lenguaje de modelado estandarizado por el Ob;ect Mavagevevt Crov
|OMG| para el desarrollo de sistemas basados en tecnologa de objetos.
A lo largo de captulo IV se analiza la estructura, alcance y objetios que tienen las
metodologas de desarrollo, su clasiicacin en base a distintos criterios y la deinicin de
algunos de los conceptos diusos en la bibliograa actual.
Ln el captulo V, siguiendo el desglose descrito en al anterior en base a la naturaleza
tecnolgica de los proyectos, se introduce cada una de las amilias de metodologas
existentes, analizando ademas los rasgos principales de la mas representatia de cada una de
ellas.
Ln el sexto, se analiza otra de las piezas undamentales en el proceso de desarrollo
de un producto sotware, pilar de la ingeniara del sotware: las herramientas CASL.
Como resultado del estudio realizado, se abren nueas posibilidades de
proundizacin, las lneas de inestigacin uturas que continen el trabajo hasta ahora
realizado. Lstas son comentadas en el captulo VII del documento.
Al inal del documento, se anexa un glosario con algunas deiniciones importantes,
y el conjunto de reerencias utilizadas a lo largo del mismo.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 3
CAPTULO II PARADIGMA DE PROGRAMACIN
ORIENTADA A CONJUNTOS
Actualmente, el grupo de inestigacin OO1LAB |OO1LAB| de la Uniersidad de
Oiedo se encuentra desarrollando un nueo paradigma de programacin orientado a
conjuntos. Se trata de una eolucin de la orientacin a objetos, pero acercandose en
ciertos aspectos a los sistemas de gestin de reglas de conocimiento y a la programacin
lgica. Como prototipo y buque insignia del paradigma se esta disenando el lenguaje de
programacin 1evv.
La idea motor del lenguaje es solucionar los problemas que la orientacin a objetos
presenta a la hora de desarrollar sotware. Se trata de conseguir orecerle al programador de
sotware el conjunto de herramientas que necesita, necesidades que se han hecho patentes a
tras de la experiencia en el desarrollo de aplicaciones. Ln este sentido, se trata de acercar
la implementacin al analisis, alejando al programador de detalles y tareas de aspecto mas
tcnico que pueden ser obiadas o resueltas de ormas mas o menos estandar y que no
aportan nada a la implementacin del modelo de negocio del sistema desarrollado.
2.1 PROGRAMACIN ORIENTADA A CONJUNTOS
La Programacin Orientada a Conjuntos ,en adelante POC, es el paradigma,
actualmente en desarrollo, que pretende dar solucin a los problemas y limitaciones
puestos en eidencia dentro de la orientacin a objetos. Parte de la actual OO, y reconoce
la eectiidad de los modelos jerarquicos en los que sta deria, sobre todo en lo reerente
al desarrollo de interaces graicas de usuario y a la interaccin con dispositios y sistemas
externos. No obstante, basa su justiicacin en lo inlexible de los sistemas orientados a
objetos en lo reerente a la gestin del modelo de negocio que implementa. La asociacin
estatica y rgida de mtodos y objetos da lugar en ocasiones a situaciones absurdas, como la
disponibilidad de, por ejemplo, un mtodo que calcule el nmero de horas desde la ltima
ingestin en un objeto que represente un organismo ya allecido.
La disociacin de clase, mtodo y estado que propone la POC rompe uno de los
cimientos de la orientacin a objetos: la relacin uncionalidad-entidad. A continuacin se
describe el lenguaje prototipo sobre el cual se esta desarrollando el paradigma: el lenguaje
1evv.
2.2 EL LENGUAJE VENN
Dado que el paradigma se encuentra en proceso de deinicin, y que el buque
insignia que dirige su desarrollo y eolucin es el lenguaje de programacin Venn, tambin
en desarrollo, el mejor medio para deinir el paradigma es describir precisamente los
aspectos determinantes que separan al lenguaje de sus orgenes en la orientacin a objetos.
2.2.1 La Tipificacin de datos en Venn
Ll punto mas caracterstico y dierenciador del paradigma es la disociacin de los
mtodos y los atributos cuya relacin es el pilar de la orientacin a objetos. Si bien una
clase en POO iene deinida por la unin entre atributos y mtodos, en Venn la
pertenencia de un objeto a un conjunto determina la coleccin de atributos que tendra
ese objeto. La justiicacin de tan radical cambio de punto de ista con respecto al
paradigma de la orientacin a objetos la encuentra el POC en lo inlexible que supone el
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 4
ligar los mtodos a las clases en tiempo de diseno. Si como consecuencia de una tarea de
mantenimiento, el desarrollador se e obligado a anadir nuea uncionalidad a una clase,
es necesario recompilar el proyecto entero y modiicar el cdigo uente de la clase,
cdigo que no siempre estara disponible y que puede llear a tener que decompilar el
ejecutable o el bytecode para reconstruirlo. As, en Venn no existe un conjunto estatico
y limitado de mtodos asociados a la clase, sin que stos deban ser desarrollados de
orma conjunta a la clase. De esta orma, el mtodo en s toma entidad dentro del
sistema. Ln consecuencia, los objetos contendran nicamente un conjunto de atributos.
Partiendo ya de que los objetos nicamente contienen atributos, cabe abordar la
tipiicacin de los mismos. Al igual que en la POO, los objetos contendran el conjunto
de atributos determinado por la clase a la que pertenecen. Sin embargo, en POC se trata
de eitar el problema que presenta POO al jugar con distintos estados de un objeto, en
los que puede darse el caso de que conjuntos disjuntos de atributos del mismo tengan
sentido en estados distintos de orma excluyente. Ante una situacin similar, la solucin
eidente, directa y por otro lado ineitable en la POO es que la clase contenga el
superconjunto de atributos susceptibles de ser requeridos por una clase, pese a que la
existencia de dichos atributos en ciertas ases de la ida del objeto pueda perder sentido.
Pongamos por ejemplo la modelizacin en un sistema orientado a objetos de un
ain comercial. Ll sistema maneja aiones, tanto si estan en tierra como si estan en
uelo. Cuando el ain se encuentra en el aire, hay ciertos atributos y mtodos que son
necesarios por el hecho de estar olando, como la altitud, elocidad, presin de la
cabina, pedir pista, etc. Lstos miembros pierden sin embargo su signiicado cuando el
ain se encuentra en tierra, momento en el cual toman sentido otro conjunto distinto
de miembros, como el hangar donde se encuentra el ain, peticin de reisin
mecanica, abrir puertas, o apagar motores. La solucin el la POO es implementar el
superconjunto de miembros concernientes a todos los estados del ain, y por medio de
cdigo determinar si una operacin es o no actible en base al estado del ain,
deoliendo un mensaje de error en caso de que no uera as para notiicar a la clase
inocante que esa determinada operacin no puede ser realizada en ese momento.
Lxisten otras soluciones basadas en patrones de diseno ,Delegacin, mucho mas
elegantes y adecuadas, pero no son intuitias para el programador, lo que choca con uno
de los principios sobre los que se construye el paradigma.
Ln respuesta a este problema, la POC propone ampliar el concepto de tipo tal y
como ste es entendido en los lenguajes y paradigmas orientados a objetos, y acercarlo
mas al concepto que se maneja en sistemas basados en conocimiento o entornos
lgicos. Un tipo en si deine un concepto, y como tal un concepto es algo mas amplio
que un objeto sico, un concepto puede ser un estado de un objeto determinado o
tambin un rol que este cumpla en un momento dado. A estos tipos` ampliados les
daremos el nombre de Conjuntos. De esta manera, los aiones en el sistema descrito se
modelaran por medio de dos conjuntos: ain en uelo` y ain en tierra`. Los
atributos estaran asociados al conjunto, de orma que un objeto que pertenezca al
conjunto ain en uelo` contendra slo los atributos que su condicin requiera para
el correcto uncionamiento del sistema. Si un ain en tierra despegara, el objeto que lo
representa simplemente sera cambiado de conjunto, y pasara a pertenecer al conjunto
ain en uelo`, con la consecuente prdida y,o ganancia de miembros en el objeto.
Un objeto recin creado es una entidad nula, un contenedor de atributos aco sin
ningn signiicado real cuyos atributos le seran asignados tan pronto comience a
pertenecer a algn conjunto que los tenga. Ll nmero de conjuntos a los que puede
pertenecer un objeto es en principio ilimitado y tan slo esta restringido por las reglas
que el disenador del sistema establezca durante la construccin del mismo. As, se
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 5
debera establecer que los conjuntos ain en tierra` y ain en uelo` son
mutuamente excluyentes, y que sin embargo, ambos conjuntos deben ser integrados por
objetos que pertenezcan necesariamente al conjunto ain`.

Iigura J Ljemplo de Conjuntos en POC
Un objeto puede pertenecer a arios conjuntos, sin que estos tengan porqu
estar relacionados entre s. Lsto sera el equialente en POO a que un objeto pudiera
cambiar de tipo sin necesidad de que ambos estuieran relacionados por una jerarqua
de herencia.
2.2.2 Tratamiento de los mtodos
Como se expuso anteriormente, los mtodos en la POC no se encuentran
asociados a los objetos ni a los conjuntos a los que pueden pertenecer. Por el contrario,
tienen entidad en tanto en cuanto no dependen de la existencia de objeto o conjunto
alguno para su deinicin. Al igual que en la POO, los mtodos seran los encargados de
contener toda la uncionalidad de la aplicacin y de aplicar la misma a los objetos. La
orma de determinar como aplicar el mtodo, y sobre que objetos es similar al vatcbivg
de reglas de los sistemas lgicos y uncionales. As, un mtodo que se aplique sobre el
conjunto A se representara como
i, ^ovbre_aet_vetoao , A, . ,,
Voliendo al ejemplo de los aiones y los aeropuertos, el mtodo que
implemente todas las operaciones retaciovaaa. con el aterrizaje de un aparato podra tener
el siguiente aspecto:
ii, .terria_ariov, ariv_ev_rveto, aeropuertos ,
.donde ain en uelo` es, como se dijo antes, el conjunto que deine los
aiones que se encuentran en el aire, y aeropuertos es el conjunto de aeropuertos dado
de alta en el sistema. La lgica contenida en el mtodo debera ormar, entre otras cosas,
el que el objeto recogido como primer parametro cambiar de conjunto para comenzar a
pertenecer al de ain en tierra`.
Los mtodos en Venn pueden ser sobrecargados, de manera que si una ez
puesto en produccin el sistema se nos diera una excepcin en el comportamiento de
un mtodo para un nueo conjunto de objetos, se puede deinir el comportamiento del
mtodo restringido a ese conjunto.
.terria_ariov; ariv_ev_rveto, aeroverto. )
.terria_ariov; ariv_barrier_ev_rveto, aeroverto. )
Avin
Avin en
tierra
Avin en
vuelo
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 6
2.2.3 Aritmtica de conjuntos
Una de las posibles opciones que permite el trabajar con conjuntos es el empleo
de las operaciones basicas ,unin, interseccin, etc., de los mismos a la hora de
desarrollar los mtodos. Venn permite trabajar con operaciones en la deinicin de
atributos de los mtodos. As, es posible deinir un mtodo sobrecargado que realice un
determinado tratamiento sobre los objetos que pertenezcan al conjunto A, otro distintos
para los que pertenezcan al conjunto B, e incluso un tercer comportamiento para
aquellos que cumplan ambas condiciones.
^ovbre_aet_vetoao ; ., . );
^ovbre_aet_vetoao ; , . );
^ovbre_aet_vetoao ; C, . );
^ovbre_aet_vetoao ; .- C, . );
Lsto permite, entre otras muchas posibilidades, resoler los conlictos que
puedan aparecer al emplear la sobrecarga de mtodos cuando existen conjuntos
solapados entre los atributos de las distintas ersiones del mtodo.
2.2.4 Tratamiento de Contextos
Los contextos permiten deinir ambitos dentro de los cuales es posible cambiar
el comportamiento de un mtodo sin aectar al resto del sistema. Supongamos que se
esta trabajando con un mtodo de ordenacin que implementa el mtodo de la burbuja.
Por medio de la sobrecarga de mtodos conencional, es posible aplicar el mismo
cdigo de ordenacin a objetos que pertenecen a conjuntos distintos. Si los objetos
representaran personas, por ejemplo, el criterio de ordenacin habitual seria el atributo
que representa el primer apellido del objeto. No obstante, en una supuesta modiicacin
del sistema es posible que se requiera ariar, para una uncionalidad determinada, el
criterio de ordenacin de orma que el nueo discriminante uera el atributo DNI del
objeto. Ln este caso ya no podemos determinar el comportamiento del mtodo en base
al conjunto de los objetos que reciba como parametro, puesto que se trata del mismo
conjunto. Para conseguir esto, es necesario poder alterar dinamicamente el
comportamiento de un mtodo en tiempo de ejecucin sin que ello aecte al cdigo ya
escrito.
Los contextos permiten establecer una modiicacin tevorat de la
implementacin de un mtodo que se extiende desde la apertura hasta la clausura del
contexto. Ll mtodo se entiende como un manejador de posibles implementaciones,
una reerencia que tendra un nombre y apuntara a un cdigo en un momento dado. La
implementacin a la que apunte el mtodo puede ser alterada por un contexto de orma
temporal.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 7

Iigura 2 1ratamiento de sobrecarga de metodos en POO
Para que el desarrollador pueda ariar la implementacin a la que apunta un
mtodo que en el contexto general ya esta asignado ,como se e en la igura,, es
necesario que abra un nueo contexto, donde todas las redeiniciones de mtodos
tendran alidez sobre las del contexto general hasta que el contexto termine. Ll
uncionamiento es similar al ambito de las ariables dentro del los bloques y,o mtodos
en los lenguajes orientados a objetos. Si una ariable es deinida dentro de un bloque, no
es isible una ez el bloque termina. Si la ariable comparte nombre con otra de un
bloque padre, la ariable local prealece sobre la mas global.
Persona [] v = new ....;
{//Abrimos contexto (sintaxis de ejemplo)
... //Existe un mtodo compara definido anteriormente.
/*Redefinimos el comportamiento del mtodo compara, teniendo en cuenta
que el origen del cdigo del mtodo puede ser cualquier fuente externa o
interna (otro mtodo, por ejemplo o incluso el propio cdigo en forma de
String).*/
compara = new Method(...);
//Se crea el nuevo mtodo de comparacin para Personas, por ejemplo por
DNI.
ordena (v); //Se ordena el vector de personas con el nuevo mtodo
compara = new Method(...); //Se repite el proceso, por ejemplo por edad.
ordena (v); //Se ordena el vector de personas con el nuevo mtodo.
} //Fin del contexto, se puede (por ejemplo) restaurar el compara redefinido.
Ln el cdigo que se muestra en la igura se aprecia como la deinicin del
mtodo compara es sobrescrita una ez iniciado el contexto, y empleada para ordenar
los elementos de un ector por un criterio distinto al establecido inicialmente en el
sistema.

Iigura 3 1ratamiento de contextos en POC
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 8
La gestin de mtodos y contextos que caracteriza a la POC permite alterar
dinamicamente partes de la codiicacin del sistema, anadiendo, modiicando o
eliminando mtodos de orma global o acotada. Lsto dota a los lenguajes como Venn de
una gran lexibilidad que acilita los cambios tardos en los requisitos de los sistemas y
permiten una mayor adaptabilidad del sotware a las circunstancias temporales del
entorno en el que se aplica.
2.3 ADECUACIN DE LAS METODOLOGAS OO A LA POC
Parece lgico que dado que el paradigma de POC se origina como una eolucin de
la orientacin a objetos, las metodologas mas adecuadas para del desarrollo de sistemas
dentro de ste paradigma que mejor se puedan adaptar sean precisamente las empleadas en
la POO. No obstante, la ruptura con la base de la POO, es decir, con la deinicin del
concepto de objeto, hacen inadecuada la aplicacin de dichas metodologas, dado que
partiendo ya de la representacin graica que realiza cada una de los distintos modelos que
contemplan, los lenguajes de modelado como UML deberan ser adaptados a la POC. La
disociacin entre mtodos y atributos no puede ser representada mediante los diagramas
estaticos de clases del UML, dado que el mtodo no existe como entidad propia, sino como
complemento de las clases.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 9
CAPTULO III NOTACIONES Y LENGUAJES DE
MODELADO
Los lenguajes de modelado y notaciones permiten representar un sistema desde
distintos puntos de ista. Segn la RAL |Rae03|, una notacin se deine como t .i.teva ae
.igvo. covrevciovate. qve .e aaota ara ere.ar covceto. vatevatico., f.ico., qvvico., etc.`. Aplicado
en el contexto del mundo del desarrollo de sotware, una notacin se deine como
cualquiera de los diagramas que representan los distintos modelos que deinen un sistema
sotware. La notacin constituye la parte graica de los modelos, es la sintaxis graica del
lenguaje de modelado |lowler03b|. As, por ejemplo, la notacin del diagrama de clases en
orientacin a objetos deine como se han de representar los elementos y conceptos
pertenecientes al modelo, como clases, asociaciones, multiplicidad, etc. Un lenguaje de
modelado iene deinido entonces por un conjunto de notaciones, es decir, por el conjunto
de diagramas que generan dichas notaciones.
No todos los lenguajes de modelado abarcan los mismos tipos de representacin,
sin que por ello sean mas o menos adecuados. Distintos aspectos del sistema pueden ser
representados perectamente por diagramas pertenecientes a lenguajes de modelado
distintos. As por ejemplo, los diagramas entidad-relacin que se emplean para deinir el
modelo lgico de datos cuando se trabaja con bases de datos relacionales es totalmente
compatible -y complementario- con los diagramas propuestos por UML |OMG98|. De
hecho, son habitualmente empleados en proyectos basados en orientacin a objetos y
modelados por medio de UML.
Ln la mayora de los casos, los lenguajes de modelado han surgido como
herramientas complementarias a las metodologas de desarrollo, y se encuentran por tanto
muy ligados a ellas. Ln el caso de las metodologas orientadas a objetos, tanto Booch
|Booch93| como Rumbaght |Rumbaugh91| deinieron sendos lenguajes de modelado como
soporte para el desarrollo de ambas metodologas. Ln consecuencia, normalmente es dicil
discernir donde termina dicho lenguaje y donde comienza la metodologa. Ln otros casos,
el lenguaje de modelado ha sido disenado para que goce de entidad propia y, en
consecuencia, pueda ser utilizado por distintas metodologas. Lste es mas bien el caso del
UML ,|vifiea Moaetivg avgvage, |OMG98|, cuya especiicacin se desarrolla de orma
independiente a la de la metodologa para cual ue concebido, el Ratiovat |vifiea Proce.., en
adelante RUP |Jacobson00|.
Para estudiar la coneniencia o adaptabilidad de un lenguaje de modelado, el primer
paso es determinar su alcance, es decir, qu aspectos del sistema es posible cubrir
empleando el conjunto de notaciones que deine un lenguaje de modelado.
3.1 ALCANCE DE LOS LENGUAJES DE MODELADO
Los distintos lenguajes de modelado abarcan dierentes conjuntos de aspectos del
sistema objeto de analisis. Ln este apartado se tratara de identiicar el superconjunto de
aspectos del sistema susceptibles de ser modelados por uno de estos lenguajes, con el
objeto de que cualquier notacin de cualquier lenguaje de modelado pueda ser enmarcado
dentro de alguna de las siguientes categoras, centrandose siempre la clasiicacin en el
paradigma de la orientacin a objetos. Cada aspecto sera modelado por un diagrama
deinido por una notacin, por un modelo. Un modelo representa a un sistema sotware
desde una perspectia especica. Al igual que la planta y el alzado de una igura en dibujo
tcnico nos muestran la misma igura ista desde distintos angulos, cada modelo nos
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 10
permite ijarnos en un aspecto distinto del sistema. Los modelos contemplados por los
lenguajes de modelado pueden clasiicarse en voaeto. e.tatico. y voaeto. aivavico..
Los voaeto. e.tatico. deinen aspectos estructurales y arquitectnicos del sistema. Se
pueden asemejan a una oto del mismo en un momento dado, puesto que estan carentes de
toda inormacin relatia a la interaccin que se da entre los elementos que lo conorman.
Los voaeto. aivavico., por el contrario, tratan de mostrar la secuencia de eentos y
mensajes susceptibles de aparecer en el ciclo de ida del sistema. As, se encuentran ligados
a la escala de tiempo que permite ordenar los sucesos deriados de las posibles
interacciones.
3.1.1 Modelos estticos o de estructura
Son los modelos relejan la estructura estatica del sistema. Se centran en la
identiicacin y descripcin de los elementos y componentes que orman parte del
mismo, y de la orma que tiene stos de relacionarse entre s. Pese a que no todos los
lenguajes de modelado presentan los mismos modelos estaticos, y cuando lo hacen se
denominan de distinta orma, es relatiamente sencillo agruparlos por su naturaleza para
obtener una clasiicacin general de todos ellos. Los modelos mas importantes comunes
a todos los lenguajes de modelado orientados a objetos son:
1. Modelos de representacin de repositorios de datos.
Son modelos que tratan de representar la estructura de los repositorios de
inormacin sobre los se apoyara el sistema para persistir las entidades que maneje. De
entre todos ellos, destaca el modelo entidad relacin que modela repositorios
consistentes en bases de datos relacionales. Otros tipos de repositorios -bases de datos
orientadas a objetos, por ejemplo- pueden ser mejor representados con otro tipos de
notaciones, como los modelos de clases.
2. Modelos de clases
Dentro de la orientacin a objetos, representan las distintas clases que aparecen
dentro del sistema, y deinen las relaciones que comparten entre ellas. Ln practicamente
todas las metodologas orientadas a objetos se maneja un lenguaje de modelado cuyo
modelo estrella es el representado por el diagrama de clases ,Booch, OM1, RUP, etc.,.
Ll diagrama de clases sobre el que se sustenta ste modelo es propuesto por muchos
autores como un medio alido de representar modelos entidad relacin y abarcar as las
responsabilidades del modelo anterior. No obstante, es tambin rechazado por otros
muchos, alegando que no se trata mas que de un parche temporal para solucionar una
carencia eidente de los lenguajes de modelado orientados a objetos.
3. Modelos de instancias
Muestran una otograa del sistema en un momento dado de su ida. Ln lugar
de mostrar clases y sus relaciones, muestra las instancias de dichas clases. Mediante el
modelo de instancia es posible representar un ejemplo de los objetos deinidos por las
clases proenientes del modelo de clases. Ls muy til como medio de entendimiento
cuando se trabaja con relaciones complejas entre clases |lowler03b|.
4. Modelo de paquetes
Ll concepto de aqvete deine una construccin basada en la agrupacin de
distintos elementos que permita tratar el conjunto que deine como una unidad de mas
alto niel. Ln consecuencia, aquellos elementos que conormen un paquete estaran
relacionados por un rasgo comn que entrane cierta lgica a la hora de agruparlos.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 11
Normalmente se trata de rasgos uncionales, de orma que las unidades de mayor niel
de abstraccin que se deinan se correspondan con alguno -o parte- de los subsistemas
identiicados durante el analisis uncional, aunque tambin pueden agruparse por
criterios tcnicos o puramente orientados al despliegue del sistema.
5. Modelos de componentes
Representan el sistema como un conjunto de componentes, y permiten deinir
las relaciones que comparten dichos componentes. Se entendiendo el trmino covovevte
como una pieza que es independiente dentro del sistema y que, en consecuencia, puede
ser sustituida y actualizada sin impacto en el conjunto del sistema.
6. Modelos de despliegue
Los modelos de despliegue muestran la distribucin sica del sistema,
determinando qu piezas de sotware se ejecutaran en cada pieza de hardware
|lowler03b|. Muestran como se relaciona la arquitectura sotware del sistema con la
arquitectura sica donde se implantara.
3.1.2 Modelos dinmicos o de comportamiento
Relejan el comportamiento del sistema y de sus componentes. 1ratan de
representar aspectos ligados al tiempo, mostrando como interactan las distintas partes
del sistema. Los modelos dinamicos aran mucho de unas metodologas a otras, no
habiendo una correspondencia clara y concisa entre los aportados por unas y por otras.
A grandes rasgos, podemos diidir los modelos entre:
1. Modelos uncionales
Se reiere a aquellos modelos cuyo cometido es mostrar el aspecto uncional del
sistema dentro de su contexto de negocio. Deinen las transormaciones de alores de
datos que ocurren en el sistema.
Los modelos uncionales no pretenden representar las interacciones entre los
distintos elementos que conorman el sistema, sino mas bien como es la interaccin
entre el sistema y el entorno donde sera desplegado. Ll mas representatio de todos
ellos es sin duda el diagrama de casos de uso del UML, donde el objetio es relacionar a
los distintos actores que interienen en el ciclo de ida del sistema con los aspectos
uncionales que debe satisacer el mismo.
2. Modelos de comportamiento interno del sistema.
Al contrario que los anteriores, estos modelos tratan de representar las
interacciones ordenadas en el tiempo susceptibles de darse entre los distintos elementos
del sistema. Dependiendo del lenguaje de modelado, estas podran mostrarse a niel de
clases, objetos, paquetes, etc.
Dentro de esta amilia de modelos podemos destacar los basados en diagramas
de lujos de datos del analisis estructurado, una de las representaciones mas recurridas
en practicamente la totalidad de las metodologas.
3.2 EL LENGUAJE DE MODELADO UNIFICADO (UML)
Ll UML es una amilia de notaciones graicas concebida para el diseno y
descripcin de sistemas sotware orientados a objetos |lowler03b|. Se trata de un estandar
tutelado por el OMG |Omg|, consorcio creado para la gestin y publicacin de estandares
que soporten interoperabilidad en sistemas orientados a objetos. Lntre sus mayores
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 12
proyectos destaca la especiicacin de CORBA ,Covvov Ob;ect Reqve.t ro/er .rcbitectvre,
|CORBA|.
A mediados de los anos 90 existan diersos lenguajes de modelado orientados a
objetos, todos relacionados ntimamente con las metodologas para las que ueron
concebidos. Lntre ellos cabe destacar el deinido por Rumbaugh para representar
graicamente los modelos manejados por OM1 |Rumbaugh91|, el de Booch, as mismo
deinido en consonancia con la metodologa OOAD ,Ob;ect Orievtea .vati.i. ava De.igv,
|Booch93|, y el empleado por Objectory |Jacobson92|, la metodologa creada por Iar
Jacobson en la empresa de mismo nombre. Por determinadas circunstancias, los tres
autores terminaron colaborando en las ilas de Rational Sotware |Rational|, y de dicha
colaboracin surgi el primer borrador del Mtodo Uniicado, la ersin 0.8 publicada en
el OPSLAA 95.
Ante la amenaza de una nuea metodologa propietaria que lleaba camino de
conertirse en un estandar ae facto en el mercado, las empresas desarrolladores de
herramientas CASL orzaron al OMG a interenir de orma que, amparandose en la
deinicin de un estandar para el intercambio de modelos, ormalizara y estandarizara la
especiicacin del UML 1.0, lenguaje de modelado empleado por el Mtodo Uniicado de
Rational. 1ras arias reisiones, OMG adopt el UML en su ersin 1.1 como uno de sus
estandares oiciales.
Actualmente, UML se encuentra en su ersin 2.0, cuya elaboracin se extendi
desde el ano 2000, cuando se recibieron las primeras RlPs ,Reqve.t or Proo.at, hasta abril
del 2003.
3.2.1 Diagramas UML
UML en su especiicacin 2.0 describe un total de trece diagramas distintos. La
particularidad del UML es que no mantiene una relacin estricta entre los diagramas y
los elementos que stos contienen, sino que es posible y correcto el empleo de smbolos
en principio asociados a un determinado tipo de diagrama en otro distinto si de esta
orma se clariica el diseno del sistema que se esta modelando.
Los diagramas UML deinen los modelos que maneja el lenguaje de modelado.
Se pueden clasiicar en estaticos o de estructura, y dinamicos o de comportamiento.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 13

Iigura 4 Diagramas en UML 2.0
(i) Diagramas estticos o de estructura
J) Diagrama de clases
Ll diagrama de clases describe los tipos de los objetos del sistema, y las
distintas relaciones estaticas que se dan entre ellos. Los diagramas de clases muestran
tambin las propiedades y operaciones de una clase, y las restricciones que se deben
aplicar a la hora de relacionar objetos.
Las roieaaae. representan los rasgos estructurales de una clase. Ln una
primera aproximacin, se corresponderan los atributos de la clase. Sin embargo, pese
a ser un nico concepto, pueden representar bien atributos o bien asociaciones de la
clase con otras clases.
Las oeraciove. son las acciones que una clase puede llear a cabo. Lstas se
corresponden con los mtodos de la clase. Normalmente no todas las operaciones
son representadas en el diagrama de clases, slo las mas representatias, omitiendo
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 14
aquellas que pueden ser deducidas por el desarrollador, como los mtodos acce.or
1
de
los atributos de la clase.
a. retaciove. permiten representar las colaboraciones entre clases que se an a
dar en el sistema. UML contempla dierentes ormas de relacin entre clases, entre
ellas la geveratiaciv.
Ll diagrama de clases es sin duda el mas representatio, socorrido y extenso
de los arteactos propuestos por UML para el modelado del sistema. Su sencilla
transormacin el cdigo resulta atractia para los analistas y disenadores,
especialmente cuando no se dispone de suiciente tiempo material para desarrollar un
diseno detallado completo del sistema.

Iigura S Ljemplo de Diagrama Lsttico de Clases
2) Diagrama de componentes
Un diagrama de componentes muestra las organizaciones y dependencias
lgicas entre componentes .oftrare, sean stos componentes de cdigo uente,
binarios o ejecutables. Desde el punto de ista del diagrama de componentes se
tienen en consideracin los requisitos relacionados con la acilidad de desarrollo, la
gestin del .oftrare, la reutilizacin, y las restricciones impuestas por los lenguajes de

1
Mtodos get y .et que iltran el acceso a los atributos de una clase. Ll establecimiento de los alores del
atributo ha de realizarse siempre mediante la inocacin de su mtodo .etter ,set^ovbre.tribvto,, y la
recuperacin por medio de su mtodo getter ,get^ovbre.tribvto,. Ll atributo debe ser riraao para impedir el
acceso directo.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 15
programacin y las herramientas utilizadas en el desarrollo. Los elementos de
modelado dentro de un diagrama de componentes seran componentes y paquetes.
Ln cuanto a los componentes, slo aparecen tipos de componentes, ya que las
instancias especicas de cada tipo se encuentran especiicadas en el diagrama de
despliegue.
Dado que los diagramas de componentes muestran los componentes .oftrare
que constituyen una parte reutilizable, sus interaces, y sus interrelaciones, en muchos
aspectos se puede considerar que un diagrama de componentes es un diagrama de
clases a gran escala. Cada componente en el diagrama debe ser documentado con un
diagrama de componentes mas detallado, un diagrama de clases, o un diagrama de
casos de uso.
Un paquete en un diagrama de componentes representa una diisin sica
del sistema. Los paquetes se organizan en una jerarqua de capas donde cada capa
tiene una interaz bien deinida.

Iigura 6 Ljemplo de diagrama de componentes
3) Diagrama de estructuras compuestas
Se trata del mas signiicante rasgo aportado por la ersin 2.0 de la
especiicacin UML. Lstos diagramas permiten descomponer una clase en su
estructura interna |lowler03b|. De esta orma, es posible desgranar en partes los
objetos complejos del sistema.
Los diagramas de estructuras compuestas son similares a los diagramas de
paquetes, con la saledad de que estos ltimos reerencian agrupaciones dadas en
tiempo de compilacin, mientras que los aqu descritos muestran agrupaciones que se
dan en tiempo de ejecucin.
Debido a que son relatiamente recientes, no es posible ealuar el xito de
stos diagramas en el mercado real. Sin embargo, han sido muy bien acogidos por los
miembros del comit UML de OMG.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 16

Iigura 7 Ljemplo de diagrama de estructuras compuestas
4) Diagrama de despliegue
Un diagrama de despliegue UML muestra las relaciones sicas entre los
componentes hardware y sotware en el sistema inal, es decir, la coniguracin de los
elementos de procesamiento en tiempo de ejecucin y los componentes sotware
,procesos y objetos que se ejecutan en ellos,. Lstaran ormados por instancias de los
componentes sotware que representan maniestaciones del cdigo en tiempo de
ejecucin ,los componentes que slo sean utilizados en tiempo de compilacin
deben mostrarse en el diagrama de componentes,.
Un diagrama de despliegue es un grao de nodos unidos por conexiones de
comunicacin. Un nodo puede contener instancias de componentes sotware,
objetos, procesos ,caso particular de un objeto,. Ln general un nodo sera una unidad
de computacin de algn tipo, desde un sensor a un mainrame. Las instancias de
componentes sotware pueden estar unidas por relaciones de dependencia,
posiblemente a interaces ,ya que un componente puede tener mas de una interaz,.
Un nodo es un objeto sico en tiempo de ejecucin que representa un
recurso computacional, generalmente con memoria y capacidad de procesamiento.
Pueden representarse instancias o tipos de nodos que se representa como un cubo
3D en los diagramas de implementacin.
Las instancias de componentes de .oftrare muestran unidades de .oftrare en
tiempo de ejecucin y generalmente ayudan a identiicar sus dependencias y su
localizacin en nodos. Pueden mostrar tambin qu interaces implementan y qu
objetos contienen. Su representacin es un rectangulo atraesado por una elipse y
dos rectangulos mas pequenos.
Los diagramas de despliegue muestran la coniguracin en uncionamiento
del sistema, incluyendo su hardware y su sotware. Para cada componente de un
diagrama de despliegue se deben documentar las caractersticas tcnicas requeridas, el
traico de red esperado, el tiempo de respuesta requerido, etc.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 17
La mayora de las eces el modelado de la ista de despliegue estatica implica
modelar la topologa del hardware sobre el que se ejecuta el sistema. Los diagramas
de despliegue son undamentalmente diagramas de clases que se ocupan de modelar
los nodos de un sistema. Aunque UML no es un lenguaje de especiicacin hardware
de propsito general, se ha disenado para modelar muchos de los aspectos hardware
de un sistema a un niel suiciente para que un ingeniero sotware pueda especiicarla
plataorma sobre la que se ejecuta el sotware del sistema y para que un ingeniero de
sistemas pueda manejar la rontera entre el hardware y el sotware cuando se trata de
la relacin entre hardware y sotware se utilizan los diagramas de despliegue para
razonar sobre la topologa de procesadores y dispositios sobre los que se ejecuta el
sotware.
Lsta ista cubre principalmente la distribucin, entrega e instalacin de las
partes que coniguran un sistema sico. Los diagramas de despliegue se suelen
utilizar para modelar:
Sistemas empotrados: Un sistema empotrado es una coleccin de hardware con
una gran cantidad de sotware que interacta con el mundo sico. Los sistemas
empotrados inolucran sotware que controla dispositio ,motores, actuadores,
que a su ez estan controlados por estmulos externos como sensores.
Sistemas cliente-seridor: Los sistemas cliente-seridor son un extremo del
espectro de los sistemas distribuidos. Requieren tomar decisiones sobre la
conectiidad de red de los clientes a los seridores, y sobre la distribucin sica
de los componentes sotware del sistema a tras de los nodos.
Sistemas completamente distribuidos: Ln el otro extremo encontramos aquellos
sistemas que son ampliamente o totalmente distribuidos y que normalmente
incluyen arios nieles de seridores 1ales sistemas contienen a menudo arias
ersiones de componentes sotware, alguno de los cuales pueden incluso migrar
de un nodo a otro. Ll diseno de tales sistemas requiere tomar decisiones que
permitan un cambio continuo de la topologa del sistema.

Iigura 8 Ljemplo de diagrama de despliegue
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 18
S) Diagrama de objetos
Los diagramas de objetos modelan las instancias de elementos contenidos en
los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y
sus relaciones en un momento concreto. Ln UML, los diagramas de clase se utilizan
para isualizar los aspectos estaticos del sistema, mientras que los diagramas de
interaccin se utilizan para er los aspectos dinamicos del mismo. Lstos cuentan con
instancias de los elementos del diagrama de clases y mensajes eniados entre ellos.
Ln un punto intermedio podemos situar los diagramas de objetos, que contiene un
conjunto de instancias de los elementos encontrados en el diagrama de clases,
representando slo la parte estatica de un interaccin, consistiendo en los objetos
que colaboran pero sin ninguno de los mensajes intercambiados entre ellos.
Los diagramas de objetos se emplean para modelar la ista de diseno estatica
o la ista de procesos estatica de un sistema al igual que se hace con los diagramas de
clases, pero desde la perspectia de instancias reales o prototpicas. Lsta ista
sustenta principalmente los requisitos uncionales de un sistema. Los diagramas de
objetos permiten modelar estructuras de datos estaticas,
Ln general los diagramas de objetos se utilizan para modelar estructuras de
objetos, lo que implica tomar una instantanea de los objetos de un sistema en un
cierto momento. Un diagrama de objetos representa una escena estatica dentro de la
historia representada por un diagrama de interaccin. Los diagramas de objetos se
utilizan para isualizar, especiicar, construir y documentar la existencia de ciertas
instancias en el sistema, junto a las relaciones entre ellas.
Los diagramas de objetos son especialmente tiles para modelar estructuras
de datos complejas. Lidentemente puede existir una multitud de posibles instancias
de una clase particular, y para un conjunto de clases con arias relaciones entre ellas,
pueden existir muchas mas coniguraciones posibles de estos objetos. Por lo tanto, al
utilizar diagramas de objetos slo se pueden mostrar signiicatiamente conjuntos
interesantes de objetos concretos o prototpicos.
6) Diagrama de paquetes
Cualquier sistema grande se debe diidir en unidades mas pequenas, de modo
que las personas puedan trabajar con una cantidad de inormacin limitada a la ez, y
de modo que los equipos de trabajo no interieran con el trabajo de los otros.
Un paquete es una parte de un modelo. Cada parte del modelo debe
pertenecer a un paquete. Para ser uncional, la asignacin debe seguir un cierto
principio racional, tal como uncionalidad comn, implementacin relacionada y
punto de ista comn. UML no impone una regla para componer los paquetes.
Los paquetes orecen un mecanismo general para la organizacin de los
modelos,subsistemas agrupando elementos de modelado. Cada paquete corresponde
a un submodelo ,subsistema, del modelo ,sistema,. Los paquetes son unidades de
organizacin jerarquica de uso general de los modelos de UML. Pueden ser utilizados
para el almacenamiento, el control de acceso, la gestin de la coniguracin y la
construccin de bibliotecas que contengan ragmentos reutilizables del modelo.
Un paquete puede contener otros paquetes, sin lmite de anidamiento pero
cada elemento pertenece a ,esta deinido en, slo un paquete.
Los paquetes contienen elementos del modelo al mas alto niel, tales como
clases y sus relaciones, maquinas de estado, diagramas de casos de uso, interacciones
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 19
y colaboraciones. Atributos, operaciones, estados, lneas de ida y mensajes estan
contenidos en otros elementos y no aparecen como contenido directo de los
paquetes.
Las aeevaevcia. que se presentan entre elementos indiiduales, pero en un
sistema de cualquier tamano, deben ser istas en un niel mas alto. Cuando las
dependencias se dan entre paquetes, resumen dependencias entre los elementos
internos a ellos, es decir, las dependencias del paquete son deriables a partir de las
dependencias entre los elementos indiiduales.
La presencia de una dependencia entre paquetes implica que existe en un
enoque ascendente ,una declaracin de existencia,, o que se permite que exista mas
adelante en un enoque descendente ,una restriccin que limita cualquier otra
relacin,, por lo menos un elemento de relacin con el tipo de dependencia indicado
entre elementos indiiduales dentro de los paquetes correspondientes.
Las dependencias mltiples del mismo tipo entre elementos indiiduales se
agregan a una sola dependencia entre los paquetes que contienen los elementos. Si las
dependencias entre elementos contienen estereotipos, ste puede ser omitido en la
dependencia del paquete, para dar una sola dependencia de alto niel.
Una clase de un paquete puede aparecer en otro paquete por la importacin a
tras de una relacin de dependencia entre paquetes. 1odas las clases no son
necesariamente isibles desde el exterior del paquete, es decir, un paquete encapsula a
la ez que agrupa.
Ln general, un paquete no puede tener acceso al contenido de otro paquete.
Los paquetes son opacos, a menos que sean abiertos por una dependencia de acceso
o de importacin. La dependencia de acceso indica que el contenido del paquete del
proeedor puede aparecer en reerencias eectuadas por los elementos del paquete
cliente. Ln general, un paquete puede er solamente los elementos de otros paquetes
que tienen isibilidad pblica. Los elementos con isibilidad protegida pueden ser
istos nicamente por los paquetes que son descendientes del paquete contenedor de
dichos elementos. Los elementos con isibilidad priada slo son istos por su
paquete contenedor y anidados. La isibilidad tambin se aplica a las clases. Ll
permiso de acceso y isibilidad son necesarios para hacer reerencia a un elemento.
La dependencia de acceso no modiica el espacio de nombres del cliente no
crea las reerencias automaticamente, simplemente concede permiso para establecer
reerencias. La dependencia de importacin se utiliza para agregar nombres al espacio
de nombres del paquete del cliente como sinnimos de los caminos completos.
Los paquetes se dibujan como rectangulos con pestanas, y las dependencias
se muestran como lechas con lneas discontinuas. Ll operador :: permite designar
una clase deinida en un contexto distinto del actual.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 20

Iigura 9 Ljemplo de diagrama de paquetes
(ii) Diagramas dinmicos o de comportamiento
J) Diagrama de casos de uso
Un Diagrama de Casos de Uso muestra la relacin entre los actores y los
casos de uso del sistema. Representa la uncionalidad que orece el sistema en lo que
se reiere a su interaccin externa.

Iigura J0Ljemplo de diagrama de casos de uso
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son
actores, casos de uso y relaciones entre casos de uso.
.ctore.. Un actor es una entidad externa al sistema que realiza algn tipo de
interaccin con el mismo. Se representa mediante una igura humana dibujada
con lneas. Lsta representacin sire tanto para actores que son personas como
para otro tipo de actores ,otros sistemas, sensores, etc.,.
Ca.o. ae |.o. Un caso de uso es una descripcin de la secuencia de interacciones
que se producen entre un actor y el sistema, cuando el actor usa el sistema para
llear a cabo una tarea especica. Lxpresa una unidad coherente de
uncionalidad, y se representa en el Diagrama de Casos de Uso mediante una
elipse con el nombre del caso de uso en su interior. Ll nombre del caso de uso
debe relejar la tarea especica que el actor desea llear a cabo usando el
sistema.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 21
Retaciove. evtre Ca.o. ae |.o. Lntre dos casos de uso puede haber las siguientes
relaciones:
o Lxtiende: Cuando un caso de uso especializa a otro extendiendo su
uncionalidad.
o Usa: Cuando un caso de uso utiliza a otro.
Se representan como una lnea que une a los dos casos de uso relacionados,
con una lecha en orma de triangulo y con una etiqueta extiende o usa
segn sea el tipo de relacin. Ln el diagrama de casos de uso se representa tambin el
sistema como una caja rectangular con el nombre en su interior. Los casos de uso
estan en el interior de la caja del sistema, y los actores uera, y cada actor esta unido a
los casos de uso en los que participa mediante una lnea.
2) Diagrama de estados
Un Diagrama de Lstados muestra la secuencia de estados por los que pasa un
caso de uso o un objeto a lo largo de su ida, indicando qu eentos hacen que se
pase de un estado a otro y cuales son las respuestas y acciones que genera. Ln cuanto
a la representacin, un diagrama de estados es un grao cuyos nodos son estados y
cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eentos.
Un estado se representa como una caja redondeada con el nombre del estado en su
interior. Una transicin se representa como una lecha desde el estado origen al
estado destino. La caja de un estado puede tener 1 o 2 compartimentos. Ln el primer
compartimento aparece el nombre del estado. Ll segundo compartimento es
opcional, y en l pueden aparecer acciones de entrada, de salida y acciones internas.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 22
Una accin de entrada aparece en la orma evtraaa,acciv a.ociaaa donde acciv
a.ociaaa es el nombre de la accin que se realiza al entrar en ese estado. Cada ez que
se entra al estado por medio de una transicin la accin de entrada se ejecuta. Una
accin de salida aparece en la orma .atiaa,acciv a.ociaaa. Cada ez que se sale del
estado por una transicin de salida la accin de salida se ejecuta.
Una accin interna es una accin que se ejecuta cuando se recibe un
determinado eento en ese estado, pero que no causa una transicin a otro estado. Se
indica en la orma vovbre ae erevto,acciv a.ociaaa.
Un diagrama de estados puede representar ciclos continuos o bien una ida
inita, en la que hay un estado inicial de creacin y un estado inal de destruccin ,del
caso de uso o del objeto,. Ll estado inicial se muestra como un crculo slido y el
estado inal como un crculo slido rodeado de otro crculo. Ln realidad, los estados
inicial y inal son pseudoestados, pues un objeto no puede permanecer en esos
estados, pero nos siren para saber cual es la transicin inicial y inal,es,.

Iigura JJ Ljemplo de diagrama de estados
3) Diagramas de actividad
Un diagrama de actiidades puede considerarse como un caso especial de un
diagrama de estados en el cual casi todos los estados son estados accin ,identiican
una accin que se ejecuta al estar en l, y casi todas las transiciones eolucionan al
trmino de dicha accin ,ejecutada en el estado anterior,. Un diagrama de actiidades
puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten
representar transiciones internas al margen de las transiciones o eentos externos.
La interpretacin de un diagrama de actiidades depende de la perspectia
considerada: en un diagrama conceptual, la actiidad es alguna tarea que debe ser
realizada, en un diagrama de especiicacin o de implementacin, la actiidad es un
mtodo de una clase. Generalmente se suelen utilizar para modelar los pasos de un
algoritmo.
Ln general resulta adecuado utilizar diagramas de actiidades para:
.vati.i. ae ca.o. ae v.o: Durante el analisis de los casos de uso no estamos
interesados en asociar acciones a objetos, sino en entender qu acciones se
necesitan llear a cabo y cuales son las dependencias en el comportamiento.
Covrev.iv aet ftv;o ae traba;o a lo largo de dierentes casos de uso.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 23
Moaetaao ae aticaciove. vvttibito.

Iigura J2 Ljemplo de diagrama de actividad
4) Diagramas de interaccin
Los diagramas de interaccin se utilizan para modelar los aspectos dinamicos
de un sistema, lo que conllea modelar instancias concretas o prototpicas de clases
interaces, componentes y nodos, junto con los mensajes eniados entre ellos, y todo
en el contexto de un escenario que ilustra un comportamiento. Ln el contexto de las
clases describen la orma en que grupos de objetos colaboran para proeer un
comportamiento. Mientras que un diagrama de casos de uso presenta una isin
externa del sistema, la uncionalidad de dichos casos de uso se recoge como un lujo
de eentos utilizando para ello interacciones entre sociedades de objetos.
Cada caso de uso es una composicin de escenarios primarios ,lujo normal
del caso de uso, y secundarios ,lujos excepcionales y alternatios,. Por tanto, para
un caso de uso podemos deinir dierentes instancias ,escenarios, que nos ayudan a la
identiicacin de objetos, clases e interacciones entre objetos necesarios para llear a
cabo la parte de uncionalidad que especiica el caso de uso. Los escenarios
documentan el reparto de las responsabilidades que se especiican en el caso de uso.
Ll lujo de eentos de un caso de uso puede recogerse en una especiicacin
texto acompanada de distintos escenarios especiicados mediante diagramas de
interaccin ,ivteractiov aiagrav.,, donde cada diagrama sera una isin graica de un
escenario. Lxisten dos tipos de diagramas de interaccin:
a) Diagrava. ae .ecvevcia ,.eqvevce aiagrav.,.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 24
Un diagrama de secuencia muestra las interacciones entre objetos ordenadas
en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la
secuencia de mensajes intercambiados entre los objetos para llear a cabo la
uncionalidad descrita por el escenario. Ln aplicaciones grandes ademas de los
objetos se muestran tambin los componentes y casos de uso. Ll mostrar los
componentes tiene sentido ya que se trata de objetos reutilizables, en cuanto a los
casos de uso hay que recordar que se implementan como objetos cuyo rol es
encapsular lo deinido en el caso de uso.
Para mostrar la interaccin con el usuario o con otro sistema se introducen
en los diagramas de secuencia las bovvaar, cta..e.. Ln las primeras ases de diseno el
propsito de introducir estas clases es capturar y documentar los requisitos de
interaz, pero no el mostrar como se a a implementar dicha interaz.
Los diagramas de secuencia, ormalmente diagramas de traza de eentos o de
interaccin de objetos, se utilizan con recuencia para alidar los casos de uso.
Documentan el diseno desde el punto de ista de los casos de uso. Obserando qu
mensajes se enan a los objetos, componentes o casos de uso y iendo a grosso
modo cuanto tiempo consume el mtodo inocado, los diagramas de secuencia nos
ayudan a comprender los cuellos de botella potenciales, para as poder eliminarlos. A
la hora de documentar un diagrama de secuencia resulta importante mantener los
enlaces de los mensajes a los mtodos apropiados del diagrama de clases. Los
conceptos mas importantes relacionados con los diagramas de secuencia son:
Linea de vida de un objeto ,tifetive,: La lnea de ida de un objeto representa la
ida del objeto durante la interaccin. Ln un diagrama de secuencia un objeto se
representa como una lnea ertical punteada con un rectangulo de encabezado y con
rectangulos a tras de la lnea principal que denotan la ejecucin de mtodos
,actiacin,. Ll rectangulo de encabezado contiene el nombre del objeto y el de su
clase, en un ormato vovbreOb;eto: vovbreCta.e.
Activacin: Muestra el perodo de tiempo en el cual el objeto se encuentra
desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a
alguno de sus atributos. Se denota como un rectangulo delgado sobre la lnea de
ida del objeto.
Mensaje: Ll eno de mensajes entre objetos se denota mediante una lnea slida
dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
1iempos de transicin: Ln un entorno de objetos concurrentes o de demoras en
la recepcin de mensajes, es til agregar nombres a los tiempos de salida y llegada de
mensajes.
Caminos alternativos de ejecucin y concurrencia: Ln algunos casos sencillos
los caminos alternatios pueden expresarse en un diagrama de secuencias
alternatias de ejecucin. Lstas alternatias pueden representar condiciones en la
ejecucin o dierentes hilos de ejecucin , tbreaa.,.
Destruccin de un objeto Se representa como una ` al inal de la lnea de
ejecucin del objeto.
Metodos recursivos. Ls un rectangulo adyacente a la actiacin principal y con
lneas de llamada de mensajes, que indican la entrada y salida de la recursin.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 25

Iigura J3 Ljemplo de diagrama de interaccin
b) Diagrava. ae cotaboraciv ,cottaboratiov aiagrav.,.
Un diagrama de colaboracin es una orma alternatia al diagrama de
secuencia de mostrar un escenario. Lste tipo de diagrama muestra las interacciones
entre objetos organizadas entorno a los objetos y los enlaces entre ellos.
Los diagramas de secuencia proporcionan una orma de er el escenario en
un orden temporal - qu pasa primero, qu pasa despus -. Los clientes entienden
acilmente este tipo de diagramas, por lo que resultan tiles en las primeras ases de
analisis. Por contra los diagramas de colaboracin proporcionan la representacin
principal de un escenario, ya que las colaboraciones se organizan entorno a los
enlaces de unos objetos con otros. Lste tipo de diagramas se utilizan mas
recuentemente en la ase de diseno, es decir, cuando estamos disenando la
implementacin de las relaciones.
A dierencia de otras notaciones que muestran tanto el estado y el
comportamiento de la clase en el diagrama de clases, UML separa el comportamiento
de las clases en los diagramas de colaboracin. Los diagramas de clase de UML no
incluyen lujo de mensajes entre clases, es por esto que los diagramas de colaboracin
se deben crear en paralelo con los diagramas de clases. Aunque se puede indicar el
orden del lujo de mensajes en un diagrama de colaboracin numerando los
mensajes, no se suele hacer, ya que para este propsito son mejores los diagramas de
secuencia.
A continuacin se enumeran los conceptos undamentales de un diagrama de
colaboracin:
Objeto: Se representa con un rectangulo que contiene el nombre y la clase del
objeto en un ormato vovbreOb;eto: vovbreCta.e.
Lnlaces: Un enlace es una instancia de una asociacin en un diagrama de clases. Se
representa como una lnea continua que une a dos objetos, acompanada por un
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 26
nmero que indica el orden dentro de la interaccin. Pueden darse arios nieles de
subndices para indicar anidamiento de operaciones. Se pueden utilizar estereotipos
para indicar si el objeto que recibe el mensaje es un atributo, un parametro de un
mensaje anterior, si es un objeto local o global.
Ilujo de mensajes: Lxpresa el eno de un mensaje. Se representa mediante una
lecha dirigida cerca de un enlace.
Marcadores de creacin y destruccin de objetos: Puede mostrarse en la graica
qu objetos son creados y destruidos, agregando una restriccin con la palabra ver o
aetete respectiamente.
Objeto compuesto: Ls una representacin alternatia de un objeto y sus atributos.
Ln esta representacin se muestran los objetos contenidos dentro del rectangulo
que representa al objeto que los contiene.
Patrn de diseo: Un diagrama de colaboracin puede especiicar un contrato
entre objetos, parte esencial para la descripcin de un patrn de diseno. Lste
diagrama contiene todos los elementos citados de un diagrama de colaboracin,
dejando libres posiblemente los tipos exactos de algunos objetos o con nombres
genricos para los mensajes. Una instanciacin` del patrn se representa como una
elipse unida mediante lechas punteadas a los objetos o clases que participan
realmente en el patrn. Lstas lechas pueden tener roles, indicando cual es el papel
de cada elemento dentro del patrn.
Contexto: Un contexto es una ista de uno o mas elementos dentro del modelo que
colaboran en el desarrollo de una accin. Se usa para separar los demas elementos
en el modelo de este problema en particular y darle nasis. Puede mostrar slo los
detalles releantes de las clases u objetos que contiene, para resaltar su utilidad.
Objeto activo: Un objeto actio es el que contiene su propio lujo de control, a
dierencia de un objeto pasio que encapsula datos y slo reacciona al eniarle
mensajes. Un objeto actio se representa con un rectangulo de bordes gruesos.
Puede contener otros objetos pasios o actios.

Iigura J4 Ljemplo de diagrama de colaboracin
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 27
c) Diagrava. ae 1i.vatiaciv ae vteracciv ;vteractiov Orerrier Diagrav)
Los diagramas de isualizacin de interaccin han sido incorporados en la
ersin 2.0 de la especiicacin UML. Son la combinacin graica de los diagramas
de actiidad con los de secuencia. Pueden concebirse como diagramas de actiidad
en los cuales las actiidades son reemplazadas por pequenos diagramas de secuencia,
o bien como diagramas de secuencia unidos mediante la notacin de los diagramas
de actiidad empleada para representar el control de lujo en el sistema |lowler03b|.

Iigura JS Ljemplo de diagrama de visualizacin de interaccin
Dada su reciente aparicin, an no esta clara la eectiidad que estos
diagramas pueden alcanzar en aplicaciones reales.
d) Crovograva.
Los cronogramas han sido incorporados a UML como una nueo tipo de
diagrama de interaccin, donde el elemento principal sobre el que se centra la
atencin son las restricciones de tiempo. Son muy tiles para representar
restricciones temporales que aectan a cambios de estado de dierentes objetos. Lste
tipo de diagrama se ha heredado de ambitos relacionados con sistemas electrnicos
,microprocesadores, microcontroladores, etc.,.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 28

Iigura J6 Ljemplo de cronograma
3.2.2 Carencias del UML
Pese a que hoy en da se trata del lenguaje de modelado mas usado y diundido,
una gran mayora de autores coinciden en la necesidad de continuar eolucionado, como
as se esta haciendo, la especiicacin del UML. Las principales crticas en este sentido
son:
La inexistencia de medios para representar diagramas entidad-relacin. Pese
a que el mundo de la orientacin a objetos no ha escatimado esuerzos en suplir las
antiguas pero eicientes bases de datos relacionales por otro tipo de repositorios que
no chocaran de rente con el propio paradigma, el tiempo -y las curas de
rendimiento- han demostrado que, pese a que acadmicamente las bases de datos
orientadas a objetos son ideales y reducen el tiempo de desarrollo, en proyectos
reales no alcanzan nieles satisactorios de sericio.
Ln consecuencia, la realidad sigue siendo que tras un modelo sotware orientado a
objetos se encuentra -habitualmente- un repositorio de datos relacional. Lsto, desde
el punto de ista del desarrollo, obliga a las clases responsables de la gestin de la
persistencia de las entidades del sistema a aaatar ambos paradigmas. Por otro lado,
y de orma eidente, obliga a disenador del sistema a voaetar esa base de datos por
medio de las herramientas oportunas. La mas adecuada es sin duda el modelo
entidad relacin, modelo no contemplado por UML. Ll lenguaje de modelado que
nos ocupa propone el empleo de los diagramas de clases para el modelado de la base
de datos relacional. No obstante, esta orma de trabajo no ha resultado exitosa
debido, entre otras cosas, a que el diagrama de clases del sistema no tiene porqu
coincidir con el modelo entidad relacin en cuanto a entidades y -sobre todo- a
relaciones se reiere. Lsto, unido a la conianza que las herramientas de modelado de
bases de datos relacionales cta.ica. aportan a los responsables del diseno, hacen que
en la mayora de los casos se opte por incorporar a los disenos UML diagramas L-R
clasicos.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 29
Diagramas para el diseo del flujo de navegacin del sistema. Otra de las
carencias que se la achacan al UML es la ausencia de herramientas o arteactos para
plasmar el mapa de naegacin del sistema. Si bien es relatiamente sencillo
desarrollarlo mediante herramientas basicas de generacin de graicos y diagramas,
esta situacin de tibertaa ae ere.iv prooca que dependiendo del proyecto o mas
bien del responsable del diseno, debamos trabajar con diagramas semanticamente
similares pero no idnticos, con los consecuentes problemas potenciales que pueden
deriarse de los allos de interpretacin.
Martin lowler senala en |lowler03b| este diagrama con una de las carencias
importantes en UML, as como la posibilidad de manejar tablas de decisin u otros
arteactos que han gozado de xito entre los desarrolladores con lenguajes de
modelado distintos.
Representacin de modelos de arquitectura. Si bien es posible especiicar que un
determinado conjunto de clases implementan un patrn de diseno concreto, UML
no orece posibilidad de disenar patrones de diseno arquitectnicos por medio de la
parametrizacin de clases, es decir, especiicando no las clases que participan en el
patrn, sino los roles que juega cada una de esas clases. De esta orma sera posible
disenar el patrn sin necesidad de especiicar las clases concretas que lo
implementan.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 30
CAPTULO IV METODOLOGAS DE DESARROLLO
Uno de los aspectos mas discutidos e indeterminados de las metodologas de
desarrollo es precisamente su deinicin. A lo largo de la historia de la ingeniera del
sotware, distintos autores han empleado dierentes trminos para reerirse a lo que en
realidad era practicamente lo mismo, o lo que es peor, se han reerido con el mismo
trmino a actiidades o herramientas que son en esencia distintas. No hay dos
metodologas que abarquen exactamente las mismas responsabilidades, ni una deinicin
precisa y aceptada que delimite cuales deben ser cubiertas por una metodologa de
desarrollo de sotware para poder denominarse como tal. Debido a ello, es necesario aclarar
el signiicado preciso de los trminos que se manejaran a lo largo del documento, y
responder a preguntas tales como ,Cual es la dierencia y,o relacin entre ingeniera del
sotware y metodologa Metodologa de desarrollo o metodologa de analisis, ,Qu
trmino es el correcto ,Qu actiidades debe abarcar una metodologa ,Metodologa,
mtodo o proceso de desarrollo Para poder comprender la eolucin que estos conceptos
han surido durante su bree historia, es coneniente conocer los principios de lo que hoy
se denomina Ingeniera del Sotware`.
4.1 ANTECEDENTES HISTRICOS Y EVOLUCIN
Al comienzo de la era del sotware, los programas eran considerados como meros
complementos del hardware. Lran las maquinas lo que realmente se aloraba dentro de un
sistema, mientras que los programas que las controlaban se ean como piezas necesarias
pero triiales. Lsta orma de pensar, aberrante hoy en da, es comprensible si tenemos en
cuenta que los primeros desarrollos se limitaban a procesos batch sin apenas interaccin
con el usuario del sistema.
A medida que las posibilidades tecnolgicas aumentaron ,mas potencia de calculo,
nueos periricos, etc.,, el sotware increment su niel de complejidad, y pronto
comenzaron a surgir problemas con los programas que se desarrollaban .el modelo de
desarrollo inicial empleado con los procesos batch ya no ala para los nueos desarrollos.
Los equipos reducidos y poco especializados se perdan en las miles de lneas que se ean
obligados a desarrollar, y lo que era peor, a mantenerlos una ez desarrolladas. Lra el
comienzo de lo que se ino a denominar cri.i. aet .oftrare.
Ln octubre de 1968 se celebr en Alemania una conerencia organizada por la
NA1O cuyo ttulo marc el comienzo de una nuea disciplina dentro del mundo del
sotware: vgeviera aet oftrare`. Por primera ez se asume la existencia del problema
presente entonces con el sotware, y se acuna el trmino de cri.i. aet .oftrare que pronto
marcara una poca en la corta historia de la inormatica.
A raz de la conerencia, se comenz a disociar el hardware y el sotware de un
sistema, y a tratar el desarrollo del sotware como una disciplina mas dentro de las
ingenieras. Ln consecuencia, la primera reaccin por parte de los desarrolladores ue tratar
de importar las metodologas aplicadas en las ramas de ingeniera clasicas al proceso de
desarrollo de un programa inormatica. Surgen las primeras metodologas de desarrollo de
sotware, y comienza una imparable y ertiginosa eolucin de la ingeniera del sotware.
4.2 DEFINICIN Y CONCEPTOS
Ll primer problema que se debe solentar para comprender el concepto de
vetoaotoga o roce.o ae ae.arrotto es precisamente alcanzar una deinicin del mismo. Ln
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 31
consecuencia, se debe comenzar por delimitar el alcance de los distintos trminos que se
manejan en torno a la ingeniera del sotware, sus mtodos y herramientas.
Los elementos clae de la Ingeniera del sotware son los vetoao., las berravievta. y
los roceaivievto., roce.o. o vetoaotoga. |Pressman91|. Mientras que los mtodos de la
ingeniera del sotware indican cvo debe construirse el sotware desde un punto de ista
tcnico, las herramientas suministran soporte automatico o semiautomatico para estos
mtodos, y los procedimientos o procesos determinan la orma de aplicar los mtodos y
emplear las herramientas para acilitar el desarrollo racional y oportuno del sotware.
4.2.1 Mtodos de Ingeniera del software
Un mtodo de ingeniera del sotware es un enoque estructurado para el
desarrollo de sotware cuyo propsito es acilitar la produccin de sotware de alta
calidad de una orma asequible econmicamente |Sommerille02|, indicando cmo
construir tcnicamente el sotware. Los mtodos abarcan un amplio espectro de
actiidades que incluyen: planiicacin y estimacin de proyectos, diseno de estructuras
de datos, arquitectura de programas y procedimientos algortmicos, codiicacin,
pruebas, mantenimiento, y otros |Pressman91|. La relacin de tareas cubiertas ara de
un mtodo a otro ,existen mtodos mas completos que otros,, y a lo largo del tiempo,
dado que la eolucin tecnolgica ha ido abriendo nueas posibilidades en el desarrollo
del sotware, y en consecuencia, han ido apareciendo nueas necesidades en los
procesos de desarrollo.
1odos los mtodos se basan en la idea de modelos graicos de desarrollo de un
sistema, y en el uso de estos modelos como un sistema de especiicacin o diseno
|Sommerille02|. La aplicacin de un mtodo u otro es una decisin que depende de
diersos actores, algunos objetios -como la adecuacin del mtodo al enoque del
proyecto ,por ejemplo, la orientacin a objetos y OM1 |Rumbaugh91|,, y otros
subjetios o circunstanciales, como las preerencias del responsable del desarrollo, la
disponibilidad de herramientas o la imposicin por parte de la organizacin.
Los mtodos incluyen una ariedad de componentes dierentes.
Descripciones del modelo del sistema
Descripciones de los modelos el sistema que se desarrollara y la notacin
utilizada para deinir estos modelos. Por ejemplo, modelos de objetos, de lujo de
datos, de maquina de estado, etc.
Reglas
Restricciones que siempre aplican a los modelos de sistemas. Por ejemplo, cada
entidad de un modelo de sistema debe tener un nombre nico.
Recomendaciones
Descripciones de las actiidades que deben seguirse para desarrollar los
modelos del sistema y la organizacin de estas actiidades.
Guas de proceso
Descripciones de las actiidades que deben seguirse para desarrollar los
modelos del sistema y la organizacin de estas actiidades. Por ejemplo, imponer
que los atributos de los objetos deban ser documentados antes de deinir las
operaciones asociadas al objeto.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 32
4.2.2 Herramientas
Las herramientas de la ingeniera del sotware suministran un soporte
automatico o semiautomatico para los mtodos |Pressman91|. Cuando distintas
herramientas se integran de orma que la inormacin creada por una pueda ser
empleada por otra, se establece un sistema de soporte al desarrollo de sotware
denominado CASL ,Ingeniera del Sotware Asistida por Computadora,. CASL
comprende un amplio rango de dierentes tipos de programas que se utilizan para
ayudar a las actiidades del proceso de sotware |Sommerille02|, como el analisis de
requisitos, el modelado de sistemas, la depuracin y las pruebas. Ln la actualidad, todos
los mtodos cuentan con su propia tecnologa CASL asociada, como editores para las
notaciones utilizadas por el mtodo, mdulos de analisis que eriican que el modelo del
sistema est acorde con las reglas del mtodo, generadores de inormas que ayudan a
crear la documentacin del sistema, generadores de cdigo o guas de proceso. Las
herramientas CASL se pueden clasiicar en:
CASL de alto nivel, cuando el propsito es ayudar al analisis y al diseno,
dado que ayudan en las ases iniciales del proceso de sotware.
CASL de bajo nivel, cuando estan disenadas para ayudar a la
implementacin y pruebas, como los depuradores, sistemas de analisis de
programas, generadores de casos de pruebas y editores de programas.
Mas adelante en el documento se trataran con mas detalle las herramientas
CASL.
4.2.3 Metodologas o procesos de desarrollo
Ll trmino metodologia mas adecuado dentro del contexto de este estudio de
los presentes en el diccionario de la Real Academia de la Lengua Lspanola es:
Cov;vvto ae vetoao. qve .e .igvev ev vva ivre.tigaciv cievtfica o ev vva eo.iciv
aoctrivat.
Rumbaugh aport la siguiente deinicin de metodologa, entendindola dentro
del contexto del desarrollo de sotware:
|va vetoaotoga ae ivgeviera .oftrare e. vv roce.o ara ta roavcciv orgaviaaa aet
.oftrare, evteavao vva cotecciv ae tecvica. reaefiviaa. , covrevciove. ev ta. notaciones. |va
vetoaotoga .e re.evta vorvatvevte covo vva .erie ae a.o., cov tecvica. , votaciove. a.ociaaa. a caaa
a.o... o. a.o. ae ta roavcciv aet .oftrare .e orgaviav vorvatvevte ev vv cicto ae riaa cov.i.tevte
ev raria. fa.e. ae ae.arrotto. Rvvbavgb1.
Algunos autores emplean el trmino roce.o ae ae.arrotto ae .oftrare para
denominar, sino exactamente, practicamente el mismo concepto. Para Pressman, se trata
de vv varco ae traba;o ae ta. tarea. qve .e reqvierev ara cov.trvir .oftrare ae atta catiaaa
|Pressman91|. Segn Sommerille, se trata del cov;vvto ae actiriaaae. , re.vttaao. a.ociaao. qve
roavcev vv roavcto ae .oftrare |Sommerille02|. Lstas actiidades son lleadas a cabo por
los denominados ingenieros de sotware. La ILLL aporta una deinicin para el trmino
proceso de desarrollo de software mas global: .ticaciv ae vv evfoqve .i.tevatico,
ai.citivaao , cvavtificabte bacia et ae.arrotto, oeraciv , vavtevivievto aet .oftrare; e. aecir, ta
aticaciv ae ivgeviera aet .oftrare.
Ln adelante, este en este documento se empleara el trmino metodologia para
reerirse a lo anteriormente deinido, con objeto de clariicar y uniicar las ideas y
isiones aportadas por los distintos autores que aqu se citen.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 33
Un proceso de sotware -o proceso de desarrollo de sotware- determina qviev
esta haciendo qve, cvavao y covo alcanzar un determinado objetio, deiniendo la
secuencia en la que se aplican los mtodos, las entregas ,documentos, inormes, ormas,
etc., que se requieren, los controles que ayudan a asegurar la calidad y coordinar los
cambios, y las directrices que ayudan a los gestores del sotware a ealuar el progreso del
proyecto |Pressman91|. Ln la ingeniera del sotware el objetio es construir un
producto sotware o mejorar uno existente |Jacobson00|. Un proceso eectio
proporciona normas para el desarrollo eiciente de sotware de calidad, capturando y
presentando las mejores practicas que el estado actual de la tecnologa permita. Ln
consecuencia, reduce el riesgo y hace el proyecto mas predecible.
Ll alcance y los objetios de una metodologa de sotware estan supeditados a
los actores de tecnologa, herramientas, personas y patrones de organizacin
|Jacobson00|.
La 1ecnologia. La metodologa debe construirse sobre las tecnologas -
lenguajes de programacin, sistemas operatios, equipos, estructuras de red,
entornos de desarrollo, etc.- existentes en el momento de aplicacin del
proceso.
Las Herramientas deben desarrollarse de orma paralela a la metodologa,
dado que son esenciales en su aplicacin.
Las Personas. Ll creador de una metodologa debe limitar el conjunto de
habilidades necesarias para trabajar en el proceso a las habilidades que los
desarrolladores actuales poseen, o apuntar aquellas que los desarrolladores
puedan obtener rapidamente.
Patrones de organizacin. La metodologa debe adaptarse a las realidades del
momento. No siempre a a ser posible disponer de los periles deseados ni de
las circunstancias ptimas de trabajo para llear aplicar la metodologa. Multitud
de actores no tcnicos ,rotacin de los miembros del equipo de desarrollo,
cambio de cliente, alta de motiacin de los desarrolladores, etc., pueden
aectar la marcha inicialmente preista para el proyecto.
Ll nmero y la naturaleza de las actiidades cubiertas por una metodologa que
aparecen en un proyecto sotware dependen en gran medida de las circunstancias del
mismo. No obstante, existen cuatro actiidades undamentales comunes a todos los
proyectos |Sommerille02|:
1. .ecificaciv aet .oftrare. Lsta actiidad deine la uncionalidad del sotware, y las
restricciones sobre su operacin. Ln base al resultado obtenido, se construira el
producto durante las siguientes ases del proyecto.
2. De.arrotto aet .oftrare: Ln base a la especiicacin resultado de la anterior
actiidad, se construye el sotware de orma que cumpla todos los requisitos y
restricciones solicitados por el usuario.
3. 1atiaaciv aet .oftrare: Ll sotware debe ser alidado para asegurar que el
producto generado es exactamente lo que el cliente quiere.
4. rotvciv aet .oftrare: Ll sotware debe eolucionar para incorporar los cambios
solicitados por el cliente.
Lstas actiidades son organizadas de dierente orma dependiendo de la
metodologa, y desarrolladas con dierentes nieles de detalle. La duracin y resultados
de cada actiidad aran.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 34
Lntre los requisitos que debe cumplir una metodologa se pueden citar
|Dorman9| los siguientes:
La metodologa esta aocvvevtaaa: el procedimiento de uso de la metodologa esta
contenido en un documento o manual de usuario.
La metodologa es reetibte: cada aplicacin de la metodologa es la misma.
La metodologa es ev.evabte: los procedimientos descritos tienen un niel
suicientemente detallado y existen ejemplos para que personal cualiicado
pueda ser instruido en la metodologa.
La metodologa esta basada en tecvica. robaaas: la metodologa implementa
procedimientos undamentales probados u otras metodologas mas simples.
La metodologa ha sido ratiaaaa: la metodologa ha uncionado correctamente
en un gran nmero de aplicaciones.
La metodologa es aroiaaa al problema que quiere resolerse.
4.3 MODELOS DE PROCESO
Ll modelo de proceso que sigue una metodologa para desarrollar un producto
sotware es sin duda uno -si no el mas- de sus rasgos mas caractersticos. A su ez, puede
ser tambin el actor determinante que dierencie un proyecto con xito de un proyecto
allido que no alcance los objetios planteados en los tiempos acordados. Ll modelo de
proceso define el ciclo de vida que se va a aplicar sobre el proyecto.
La eleccin del modelo de proceso, habitualmente ligado a la metodologa, no es
ninguna ciencia exacta, sino que se encuentra irmemente relacionado con la naturaleza y
circunstancias puntuales del proyecto objeto de desarrollo. Ante un proceso de toma de
requisitos maniiestamente incompletos, o un cliente inseguro que no tiene claro lo que
desea, sera mas adecuado un modelo de proceso basado en la especiicacin de prototipos
e iteraciones cortas. Si por el contrario se trata de un proyecto oluminoso cuyos requisitos
no an a ariar por encontrarse muy madurados o bien condicionados a elementos estables,
es posible que conenga mas abordarlo mediante un modelo de proceso mas clasico.
Cada metodologa deiende un modelo de proceso concreto. No obstante, queda
bajo la responsabilidad del analista el lexibilizar el mismo, no por ello abandonando las
lneas generales que dicta dicha metodologa. De hecho, en ciertas ocasiones el responsable
del proyecto puede erse obligado a ello, si por ejemplo no cuenta con la especiicacin
completa en un plazo razonable.
Lxisten arios modelos de proceso posibles, muchos como resultado de la
combinacin de otros distintos. Los dierentes autores no se ponen de acuerdo en una
clasiicacin nica, por lo que lo que aqu se presenta es una sntesis razonada de los
recogidos a lo largo de arias publicaciones:
Moaeto Cta.ico o ev Ca.caaa.
De.arrotto rotvtiro o Prototiaao.
.irat.
De.arrotto vcrevevtat.
De.arrotto forvat ae .i.teva..
Coaificar , Corregir.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 35
Moaeto. ae Proce.o briao..
4.3.1 Modelo Clsico o en Cascada
Ls el mas antiguo de todos los modelos de ciclo de ida y sire de modelo para
otros modelos de ciclos de ida. Ln un modelo en cascada un proyecto progresa a
tras de la siguiente secuencia ordenada de pasos |Sommerille02|:
1. .vati.i. ae reqvi.ito..
2. Di.evo gtobat.
. Di.evo aetattaao.
1. Coaificaciv , aevraciv.
:. Prveba aet .i.teva.

Iigura J7 Modelo clsico en cascada
Ll modelo contiene una serie de etapas que no se solapan, y el proyecto se a
reisando tras cada una de las etapas. Para poder pasar a la siguiente etapa se tiene que
haber conseguido todos los objetios de la etapa anterior, es un proceso secuencial.
1iene una buena aplicacin cuando el problema es estable y cuando se trabaja
con metodologas tcnicas conocidas. Lste modelo sera apropiado para la migracin de
una aplicacin o a una ersin de mantenimiento bien deinida.
Con este modelo se tiene un seguimiento de todas las ases del proyecto y del
cumplimiento de todos los objetios marcados en cada etapa tanto de costes, echas de
entrega y lo mas importante que pueden comprobar al inal de cada etapa si el proyecto
cumple todas las necesidades del usuario. A su ez esto supone un problema ya que si el
usuario se da cuenta de que alta una tarea de la empresa en el proyecto una ez pasada
esta etapa, el trabajo que hay que realizar se retrasa en echas de entrega y el coste es
mayor. Por lo tanto esto produce un racaso en la industria ya que es reacio a las
Anlisis de
Requisitos
Diseo Global
Diseo Detallado
Codificacin y
depuracin
Prueba del
Sistema
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 36
modiicaciones de ltima hora, algo que por otro lado se presenta como una
circunstancia inherente al proceso de desarrollo de sotware.
Por este motio se puede modiicar el modelo en cascada pudiendo pasar de una
etapa a la anterior, pero suele ser dicil ya que hay que rehacer la etapa anterior, este
modelo es el ciclo de ida del salmn. Por lo tanto este es un modelo poco apropiado
para proyectos con echa de entrega corta, pero su rendimiento puede mejorar
notablemente ariando el modelo de la cascada pura.
Variaciones sobre el Ciclo de Vida en Cascada
Ll Ciclo de Vida en Cascada puede surir una serie de modiicaciones para
aumentar su eiciencia. Una de estas ariaciones puede ser t a.bivi o Ca.caaa cov fa.e.
.otaaaa., en el que para eitar algunos inconenientes del modelo en cascada solapando
sus etapas, pero este enoque genera nueos problemas ya que debido al solapamiento
los hitos resultan mas ambiguos y esto hace mas dicil trazar el proceso correctamente.
Otra ariacin sobre el Ciclo de Vida en Cascada sera el Ciclo de ida en
cascada con vbro,ecto., en el que se permite la ejecucin de algunas de las tareas de la
cascada en paralelo, pero esta modiicacin tiene el problema que la planiicacin tiene
que ser mucho mas cuidadosa, aunque se gana elocidad.
4.3.2 Desarrollo Evolutivo o Prototipado
Ll modelo de proceso eolutio orece el control que se obtiene con la entrega
por etapas y la lexibilidad que se obtiene con el prototipo eolutio. Lste modelo
puede ajustarse para proporcionar el control y la lexibilidad que se necesita.
Ln este modelo an desarrollando ersiones anadiendo uncionalidad a las
anteriores y se le an mostrando al cliente. Lste proceso se repetira hasta agotar el
tiempo, el presupuesto o hasta que el cliente este satisecho.
Para poder empezar a desarrollar ersiones deberemos haber disenado el ncleo
del sistema y su globalidad. Ln el desarrollo eolutio se enatiza en el ncleo del
sistema que probablemente no sera modiicado por la realimentacin del cliente.
Ll modelo resulta adecuado cuando los requisitos cambian con celeridad,
cuando el cliente es contrario a acilitar los requisitos y especiicaciones o cuando no
esta clara la orma del area de aplicacin.

Iigura J8 Desarrollo evolutivo
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 37
Sommerille dierencia dos lneas distintas dentro del modelo de proceso de
desarrollo eolutio |Sommerille02|:
Ll De.arrotto etoratorio, cuyo objetio es trabajar con el cliente para obtener cuanto
antes la relacin de requisitos inales bien detallados. Se comienza por las partes del
sistema que mejor se comprenden, y se a eolucionando el prototipo inicial hasta
que, por medio de la incorporacin de nueos requisitos, se obtiene el producto
inal.
Ll desarrollo basado en Prototio. ae.ecbabte., que se centra mas en aquellas partes de
los requisito que peor se comprenden, experimentando con ellas con el objetio de
lograr un conocimiento pleno del sistema antes de abordar ninguna ersin estable
del producto.
Lste modelo de proceso conllea algunas entajas, como la continua reisin
por parte del cliente de los progresos del proyecto. De esta orma, dado que se parte de
requisitos dbilmente establecidos, los posibles allos conceptuales, carencias, u otros
posibles motios de disconormidad por parte del cliente pueden ser detectados antes
de que impliquen cambios traumaticos en el sistema. Ademas, esta orma de trabajar
permite la modiicacin de requisitos sobre la marcha, y una mayor implicacin por
parte del cliente en la ase de pruebas y alidacin de requisitos.
Sin embargo, pese a estas entajas, este modelo de proceso presenta algunos
inconenientes que lo inalidan para abordar proyectos de determinada ndole.
Ln primer lugar, se le achaca una pobre isibilidad del proceso global, dado que
los desarrolladores trabajan con pequenas ersiones y pueden no tener claro el alcance
inal del proyecto.
Por otro lado, debido a la naturaleza de las etapas, este modo de trabajo deria
en una especiicacin pobre del sistema. Sin embargo, el mas importante de todos los
problemas que presenta es la imposibilidad de conocer a priori el tiempo de desarrollo
total del proyecto, algo que, debido a modelo de negocio que actualmente se sigue en el
sector priado del mundo del sotware, conierten al modelo en poco menos que una
utopa
Ln consecuencia, se presenta como un modelo alido para proyectos pequenos
o medianos, o bien para subproyectos dentro de un proyecto te mayor tamano, en
deinitia, para el desarrollo de proyectos de corta ida.
4.3.3 En Espiral
Ll modelo de la espiral es un modelo orientado a riesgo que diide el proyecto
sotware en miniproyectos. Cada proyecto se encargara de resoler uno o arios riesgos
hasta que estn todos controlados. Una ez que estn los riesgos mas importantes
controlados se inaliza igual que el ciclo de ida en cascada.
Ln el ciclo de ida en espiral localizan los riesgos, genera un plan para
manejarlos y se establece una aproximacin a la siguiente iteracin. Con cada iteracin
se produce una aproximacin al producto inal.
Ln el modelo en espiral se comienza con una parte pequena del proyecto y se
expande tras reducir los riesgos para la siguiente iteracin. Ln cada iteracin seguimos
los siguientes pasos:
1. Detervivar ob;etiro., attervatira. , tvite..
2. aevtificar , re.otrer rie.go..
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 38
. ratvar ta. attervatira..
1. Ceverar evtrega. ae e.ta iteraciv, , covrobar qve .ov correcta..
:. Ptavificar ta .igvievte iteraciv.
. i .e aeciae e;ecvtar ta .igvievte iteraciv, ba, qve e.tabtecer vv evfoqve ara etta.

Iigura J9 Desarrollo en espiral
Ln este modelo las primeras iteraciones son menos costosas y a medida que se
aanza aumenta el coste. La mayor entaja que presenta este modelo de proceso es la
disminucin de riesgos en el proyecto, dado que la continua ealuacin y analisis de
riesgos permite tenerlos controlados. Al inal de cada iteracin, se obtienen los puntos
de eriicacin del proyecto, y los riesgos no superables son detectados con tiempo
suiciente para tomar las decisiones pertinentes para eitarlos. Sin embargo, este
ejercicio de control continuo sobre la marcha del proyecto implica un aumento
considerable en los costes del mismo, dado que requiere una mayor inersin en tiempo
y recursos humanos. Ademas, es dicil llearlo a cabo, y requiere que los implicados en
el control del proyecto cuenten con la suiciente experiencia que les permita adelantarse
a la aparicin de un problema.
4.3.4 Desarrollo Incremental
Ll modelo de proceso basado en desarrollo incremental se basa en una
identiicacin inicial por parte de los clientes de los sericios mas importantes del
sistema. A partir de este punto, se deinen arios incrementos donde cada uno aporta un
nueo subconjunto de la uncionalidad total del sistema |Sommerille02|. La prioridad
de los sericios determinara el incremento en el que deben ser abordados, de orma que
los sericios mas crticos apareceran en las primeras ersiones del sistema, y aquellos
menos importantes seran relegados para el inal del desarrollo.
De esta orma, el modelo de proceso a describiendo ciclos que pueden contar
con modelos de proceso distintos. Cada ciclo se era como un miniproyecto, de orma
que no deberan aceptarse cambios en los requisitos entre incrementos, pero si podran
abordarse una ez se termine cada una de estas ersiones.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 39
Lste modelo de proceso permite a los clientes comenzar la explotacin del
producto antes de que ste se encuentre terminado por completo, y en consecuencia,
detectar las posibles carencias del sistema mas temprano, de orma que sea posible
reducir el impacto de los cambios en los requisitos del sistema. Por otro lado, dado que
los sericios crticos son los primeros en ser desarrollados, y seran probados de nueo
en cada iteracin del sistema, seran sometidos a mas pruebas que aquellos de menor
importancia, siendo mas actible el conseguir la aceptacin del cliente.
Ll tamano de los incrementos depende de cada proyecto, y de las circunstancias
en las que se desarrollo. Sommerille pone la rontera en 20.000 lneas de cdigo
generado por cada incremento |Sommerille02|, pero ponderar la coneniencia del
tamano de una entrega en base al nmero de lneas programadas es un criterio
inadecuado y, sobre todo, ariable entre tecnologas y desarrolladores.
Un posible problema con el que se puede encontrar el responsable del proyecto
a la hora de aplicar este modelo de proceso es la interdependencia entre los distintos
mdulos del producto, puesto que es probable que el ncleo del sistema o pieza mnima
a desarrollar sea grande e indiisible.
4.3.5 Desarrollo Formal de sistemas.
Se trata de un modelo de proceso muy similar al modelo en cascada, con la
saledad de que el objetio en este caso es obtener una especiicacin ormal del sistema
en lenguaje matematico. Una ez se cuenta con la especiicacin ormal, el proceso de
implementacin clasico se sustituye por un conjunto de transormaciones en las que la
especiicacin ormal se reina hasta llegar al programa objeto.
Las transormaciones son cercanas, de orma que sea relatiamente sencillo
alidar la alidez de cada uno de los modelos que se generan desde que se parte de la
especiicacin ormal hasta que se cuenta con una ersin inal del producto.
Lste modelo de proceso apenas es aplicado en proyectos reales, por el
sobreesuerzo que conllea durante el proceso de especiicacin, y la complejidad del
mismo.
4.3.6 Codificar y Corregir
Ll modelo codiicar y corregir se basa en la creencia de que, en determinados
tipos de proyectos, no merece la pena inertir tiempo en buscar el modelo mas idneo
para el proyecto. Ls decir en este modelo no se pierde el tiempo en la planiicacin, en
la calidad, en los documentos que hay que realizar cuando se terminan etapas o en
cualquier otra actiidad que no sea la codiicacin. Debido a ello, este modelo requiere
recursos humanos con mucha experiencia y una gran cantidad de conocimientos.
Al no seguir un modelo no se cuenta con ningn medio de er si se cumplen las
expectatias creadas, lo cual es supone problema si se encuentra un error casi al inalizar
el proyecto. Ln deinitia, no suele ser un modelo alido para el desarrollo de proyectos
grandes o medianos en los que se requiere distribuir la responsabilidad y el
conocimiento entre distintos recursos del equipo de desarrollo.
4.3.7 Modelos de Proceso Hbridos
Los modelos descritos hasta ahora podran ser clasiicados como los rivitiro..
1al y como se indic anteriormente en este documento, no existe una clasiicacin nica
de los modelos de proceso que pueden seguir las distintas metodologas de desarrollo.
Distintos autores bautizan mediante trminos dierentes lo que en realidad es
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 40
practicamente lo mismo. As por ejemplo, lo que Pressman denomina Prototiaao
|Pressman91|, Sommerille lo llama De.arrotto rotvtiro |Sommerille02|. Otros autores
describen modelos que, en realidad, pueden concebirse como eolucin o combinacin
de los aqu descritos hasta ahora.
As por ejemplo, RUP |Jacobson00| deine su modelo de proceso como iteratiro e
ivcrevevtat, lo cual podra deinirse en trminos de desarrollar pequenos modelos en
cascada dentro de un desarrollo incremental. XP |Acebal02| eoluciona el modelo de
RUP haciendo los ciclos de ida mucho mas cortos que los de la primera, pero
manejando en deinitia modelos en cascada para cada uno de los subproyectos que
maneja, con la saledad de la ase de pruebas, la cual extiende a lo largo de todo el
proceso de desarrollo
2
.
4.4 ALCANCE
Segn Pressman, las principales actiidades de una metodologa |Pressman91|
son:
a aefiviciv , ae.criciv aet robteva qve .e ae.ea re.otrer.
t ai.evo , ae.criciv ae vva .otvciv qve .e a;v.te a ta. vece.iaaae. aet v.vario.
a cov.trvcciv ae ta .otvciv.
a rveba ae ta .otvciv ivtevevtaaa.
Sin embargo, este es otro punto de discordia entre las opiniones de los distintos
autores. Ll cometido exacto que debe cumplir una metodologa, o en trminos mas
esquematicos, las actiidades del proceso de desarrollo que debe cubrir para poder
denominase como tal, no se encuentran deinidas. As, dierentes metodologas cubren
actiidades distintas del ciclo de desarrollo. Lxisten metodologas que extiende su
ambito a todas las labores de control, documentacin y burocracia inherentes al
desarrollo de un proyecto sotware. Ll caso de Mtrica responde a este peril, puesto
que llega a describir los documentos que deben producirse como resultado de cada una
de las actiidades abordadas en un proyecto. Otras metodologas por el contrario se
limitan a guiar los aspectos tcnicos del desarrollo, lexibilizando aspectos burocraticos
como los ormatos de documentos, y dejandolos abiertos al gusto del responsable del
proyecto, o de la organizacin cliente.
Pese a la indeinicin de la estructura del concepto de metodologa, si que es
posible clasiicar el superconjunto de actiidades susceptibles de ser incluidas en
cualquiera de ellas. Ln una primera instancia, es posible distinguir entre actiidades
tcnicas o de desarrollo, y actiidades relacionadas con la administracin y gestin del
proyecto.
4.4.1 Actividades Tcnicas o de desarrollo.
Las actiidades de desarrollo manejan la complejidad mediante la construccin
de modelos de los dominios del problema o del sistema |Bruegge02|. Dentro de las
actiidades de desarrollo, se identiican las siguientes:
1. Obtevciv ae reqvi.ito..

2
Mediante el empleo de las tcnicas de vtegraciv covtivva y Prveba. |vitaria..
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 41
2. .vati.i.
. Di.evo aet .i.teva
1. Di.evo aetattaao
:. vtevevtaciv
6. Prveba.
(i) Obtencin de los requisitos.
Para que un esuerzo de desarrollo de sotware tenga xito, es esencial
comprender perectamente los requisitos del sotware |Pressman91|.
Independientemente de lo bien disenado o codiicado que est un programa, si se ha
analizado pobremente, decepcionara al usuario y desprestigiara al que lo ha desarrollado.
Ls dicil comprender la naturaleza de los problemas del cliente, y exige un esuerzo
considerable por parte del ingeniero de sotware, dado que en ocasiones ha de
conertirse en un autntico experto en procesos que nada tienen que er con la
disciplina que l conoce. Las descripciones de los sericios y restricciones son los
requisitos para el sistema, y el proceso de descubrir, analizar, documentar y eriicar
estos sericios y restricciones se llama obtencin o ingenieria de requisitos
|Sommerille02|.
Gran parte de los racasos en este tipo de proyectos se deben a que el cliente no
esta contento con el producto que le es entregado, y requiere cambios que, en muchas
ocasiones, pueden aectar de manera importante a la estructura del producto. Lxisten
dos posibles razones por las cuales se puede dar esta circunstancia. La primera, es que el
equipo no haya sido capaz de comprender qu es exactamente lo que el cliente desea
que se le desarrolle, y la segunda, bastante habitual, es que es el mismo cliente el que no
tiene demasiado claro lo que quiere. Distintos departamentos de la empresa cliente
pueden tener isiones distintas del mismo proceso, o intereses enrentados con respecto
a determinados procedimientos, de orma que es practicamente imposible alcanzar una
solucin de compromiso que contente a ambas dos partes, lo cual conlleara a un
ineitable descontento por parte del cliente con respecto al producto inal. Pongamos
por ejemplo un sistema de gestin de proyectos en una empresa de sotware grande. Ll
departamento de calidad, en sus unciones de cliente, solicita a la empresa desarrolladora
que los datos econmicos reerentes al presupuesto de cada proyecto sean introducidos
en el sistema por el departamento inanciero. Por otro lado, el departamento inanciero,
con objeto de eitar la carga tediosa de tener que introducir toda esa inormacin,
solicita que sta sea introducida en el sistema por los jees de proyecto. Ln este caso,
una solucin abierta que permitiera la insercin del presupuesto a ambos periles
tampoco supone una solucin al problema, puesto que el objetio de cada uno de los
dos departamentos no es tener la capacidad de realizar esa uncin, sino proocar que
dicha tarea tenga que ser realizada por el otro departamento, liberandose de una carga
de trabajo puramente administratia.
Ll analisis de requisitos es, pues, un proceso de descubrimiento, reinamiento,
modelizacin y especiicacin |Pressman91|, e incluso a eces de reingeniera de
procesos lo que a mas alla de los objetios de la ingeniera del sotware.
Con objeto de eitar erse inolucrado en medio de este tipo de batallas, el
equipo de desarrollo basa sus objetios y obligaciones en el documento de requisitos. Ll
documento de requisitos deine el contrato que el cliente y equipo desarrollador
mantienen. Una ez irmado y aprobado ste documento, los requisitos el sistema estan,
al menos en teora, congelados, y no pueden ser modiicados ni extendidos sin un
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 42
acuerdo bilateral que implicara, en la mayora de los casos, una dilatacin del tiempo de
desarrollo y el coneniente ajuste en la planiicacin del proyecto.
Ln base a la naturaleza del requisito, este puede clasiicarse como reqvi.ito
fvvciovat o como reqvi.ito vo fvvciovat.
Los reqvi.ito. fvvciovate. son aquellos que deinen un area de uncionalidad que
debe soportar el sistema. Son perectamente entendibles por el cliente, dado que
habitualmente estan compuestos por el conjunto de reglas de negocio implicadas en el
modelo a construir.
Un reqvi.ito vo fvvciovat es una restriccin sobre la operacin del sistema.
Lspeciican propiedades del sistema, como restricciones del entorno o de la
implementacin, cotas de rendimiento, dependencias de la plataorma, acilidad de
mantenimiento, extensibilidad, y iabilidad. |Jacobson00|.
Dependiendo del autor que se consulte, la actiidad de obtencin de requisitos
puede estar o no incluida dentro de la actiidad de analisis. Dado que determinadas
metodologas separan los dos conceptos de actiidad, y orecen mtodos dierentes para
ambas dos, se opta en este documento mantenerlas separadas.
(ii) Anlisis
Durante el analisis, los desarrolladores tratan de producir un modelo del sistema
que sea correcto, completo, consistente, claro, realista y eriicable |Bruegge02|. Los
requisitos recogidos durante la ase anterior son transormados en uno o arios modelos
que describen por completo el sistema. Durante esta actiidad, aloran inconsistencias y
ambigedades que deben ser resueltas mediante la interaccin con el cliente.
(iii) Diseo del sistema.
A lo largo de esta actiidad se deinen objetios de diseno del proyecto, y se
descompone el sistema en subsistemas mas pequenos que pueden realizar los equipos
indiiduales. Se seleccionan estrategias para la construccin del sistema, como la
plataorma de hardware y sotware en la que se ejecutara el sistema |Bruegge02|, la
estrategia de almacenamiento de datos persistentes, el lujo de control global, la poltica
de control de acceso y el manejo de las condiciones de rontera. Ll resultado de un
diseno de sistema es una descripcin clara de cada una de estas estrategias, una
descomposicin en subsistemas y un diagrama de organizacin que representa el mapeo
en el hardware y sotware del sistema.
(iv) Diseo detallado
Partiendo de los documentos generados durante las ases de analisis y diseno del
sistema, se procede a completar el diseno con un alto niel de detalle. Cada uno de los
elementos o piezas del producto a construir debe ser deinido y detallado.
(v) Implementacin
Durante la implementacin, se traduce el diseno detallado a cdigo uente. Al
inal de esta ase de cuenta con el producto terminado, listo para pasar a la ase de
pruebas y alidar que el trabajo realizado cumple las expectatias del cliente.
(vi) Pruebas
Durante esta actiidad, surgen dierencias entre los modelos y el producto
construido ejecutando el sistema con conjuntos de datos de prueba. Dependiendo de la
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 43
metodologa, las pruebas a realizar durante esta actiidad seran de una o arias
naturalezas. Lntre las posibles, tenemos:
|vitaria.. Se compara el modelo de diseno con cada pieza de cdigo y subsistema.
vtegraciv, durante las cuales se integran los distintos mdulos del sistema,
detectandose en esta actiidad las posibles irregularidades en las interaces que los
separan y comunican.
Prveba. aet .i.teva, en las que se alidan los requisitos del sistema en el producto
generado, mediante la ejecucin de casos tpicos y excepcionales.
4.4.2 Actividades de administracin y gestin del proceso de
desarrollo
Las actiidades relacionadas con la administracin en un proceso de sotware se
enocan en la planiicacin y organizacin del proyecto, la superisin de su estado, el
seguimiento de los cambios y la coordinacin de los recursos para que se entregue un
producto de alta calidad, dentro de los plazos establecidos y sujeto al presupuesto
preisto. A pesar de que nueamente no existe consenso a la hora de denominar las
actiidades englobadas dentro de este conjunto, podemos aproximar que todas encajan
en alguno de los subconjuntos siguientes:
1. Comunicacin
2. Administracin de la undamentacin.
3. Administracin de la coniguracin del sotware.
4. Administracin del proyecto
5. Ciclo de ida del sotware
(i) Comunicacin.
Se trata de la actiidad mas crtica y la que consume mas tiempo en la ingeniera
del sotware |Bruegge02|. La alta de comprensin y las omisiones con recuencia
conducen a allas y retrasos cuya correccin posterior durante el desarrollo es costosa.
La comunicacin incluye el intercambio de modelos y documentos acerca del sistema y
su dominio de aplicacin, reportando el estado de los productos de trabajo,
proporcionando retroalimentacin sobre la calidad de los productos de trabajo,
proponiendo y negociando asuntos y comunicando decisiones. La comunicacin se
diiculta por la diersidad de conocimientos de los participantes, por su distribucin
geograica y por el olumen, complejidad y eolucin de la inormacin que se
intercambia.
Un ejemplo clasico de actiidad de comunicacin es la imposicin por parte del
gestor del proyecto de conenciones de notacin y,o codiicacin. Ll empleo de una
misma tcnica a la hora de arontar tareas similares por parte de miembros distintos del
equipo de trabajo acilita el entendimiento entre dichos miembros.
(ii) Administracin de la fundamentacin.
La undamentacin es la justiicacin de las decisiones |Bruegge02|. Ln lneas
generales, se trata de recoger y documentar todas las decisiones, conclusiones y
razonamientos que han desembocado en una decisin de diseno o implementacin, de
orma que ante uturos cambios, el desarrollador que desempene la tarea de
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 44
mantenimiento sea consciente del impacto que el cambio, eitando tener que repetir el
ciclo de ealuacin de la situacin que se hizo la primera ez que se abord el problema.
Ll desprecio que habitualmente se hace de esta necesidad, debido entre otras
cosas a que su ausencia es dicilmente detectable por parte del cliente, deria en la
incomprensibilidad del cdigo uente del producto, diicultando su mantenimiento
acilitando la aparicin de errores de concepto cuando un nueo desarrollador acomete
una tarea de mantenimiento.
(iii) Administracin de evolucin del software.
Bajo este ttulo se conunden una importante cantidad de tareas adyacentes al
desarrollo del producto que, pese a no ser el objeto principal del proyecto, pueden
determinar el xito o racaso del mismo. La mas importante es, sin duda, el control de
ersiones del cdigo uente, es decir, de su eolucin desde las ases tempranas de
desarrollo hasta que el producto se encuentra inalmente terminado. Ln control de
ersiones es undamental, sobre todo cuando se trata de proyectos de tamano
considerable donde colaboran arios desarrolladores simultaneamente.
Igualmente, se puede englobar dentro de esta categora de actiidad todas
aquellas tareas que resultan crticas como soporta al resto de actiidades del proyecto.
Por ejemplo, la generacin de datos de prueba, la migracin de bases de datos, la
importacin de datos reales para los entornos de preproduccin, etc.
(iv) Administracin del proyecto
Abarca actiidades de igilancia que aseguran la entrega de un sistema de alta
calidad a tiempo y dentro del presupuesto. Incluye la planiicacin, estimacin
presupuestaria, contratacin de desarrolladores y su organizacin e equipos, la igilancia
del estado del proyecto y las interenciones cuando suceden desiaciones. La
administracin de proyectos sotware suele requerir una amplia experiencia en el sector
por parte del responsable de la actiidad. Ls necesario saber identiicar los riesgos que
se pueden presentar en un proyecto, y cuando se presenten, acertar en la estimacin de
la desiacin consecuencia de dicho riesgo, de orma que la planiicacin sea actualizada
constantemente y sea consecuente con las circunstancias reales del proyecto.
(v) Control del ciclo de vida del software
Ln este caso, el trmino cicto ae riaa se reiere al modelo de proceso asociado al
proyecto, normalmente determinado por la metodologa de desarrollo que se haya
decidido aplicar al mismo. La transicin entre las distintas etapas del modelo de proceso,
el cumplimiento de los hitos que deine y otros aspectos caractersticos del mismo
requieren una labor de seguimiento por parte de los responsables del equipo de
desarrollo.
4.5 CLASIFICACIN
Lxisten distintos criterios de clasiicacin por los cuales se puede diidir el conjunto
global de metodologas de desarrollo de sotware. Dependiendo del punto de ista del
autor, determinadas metodologas pueden quedar agrupadas en una clasiicacin, y
enrentadas en otra.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 45
4.5.1 Clasificacin en base a su agilidad
lowler, en |lowler03b| diide el conjunto global de metodologas entre
burocraticas y agiles. La dierencia entre las metodologas de ambas amilias suele
determinarse por la importancia que estas le den a las actiidades de gestin y
administracin del proceso de desarrollo.
(i) Metodologas de Ingeniera o burocrticas.
Son aquellas que imponen un proceso de desarrollo de sotware disciplinado,
sujeto a ciertas normas rreas, de orma que el trabajo se desarrolle de una orma
predecible y eiciente. Lstan basadas en las metodologas aplicadas a otras disciplinas de
ingeniera. Ll mayor problema que presentan y un coste burocratico desmesurado. Ll
tiempo del proyecto se e seriamente incrementado por la necesidad de desarrollar y
sobre todo mantener grandes cantidades de documentacin, tramites y comunicaciones.
La idea es que una nica orma de desarrollar sotware, que obligue a todos los
participantes de cualquier proyecto a seguir siempre las mismas normas y pasos, elaborar
los mismos documentos, permite un alto grado de coordinacin entre los
desarrolladores del producto.
Lste tipo de metodologas es adecuado para proyectos grandes tanto en recursos
como en plazos. Cuando se trata de desarrollar un proyecto a muchos meses o incluso
anos, cobran importancia las tareas de coordinacin que propugnan este tipo de
metodologas.
(ii) Metodologas giles.
Nacen como reaccin a las metodologas burocraticas. Se caracterizan por no
estar puramente orientadas a la documentacin del proceso de desarrollo, algo que
conllea ciertas entajes y ciertos inconenientes. Se trata de mtodos mas adaptatios
que predictios, que parten de la asuncin de que los cambios en los requisitos una ez
comenzado el proceso de desarrolla es algo inherente a cualquier proceso de desarrollo
de sotware.
Los mtodos basados en la ingeniera tradicional inierten una gran cantidad de
tiempo en planiicar y disenar el producto que se a a desarrollar. La realidad de los
requisitos eternamente cambiantes es algo que las metodologas de ingeniera no
asimilan bien. Los mtodos agiles, en cambio, aceptan esta realidad y basan sus tcnicas
en preenir y asumir acilmente dichos cambios.
Se trata de metodologas orientadas mas a las personas que a los procesos, y
tiene su campo de accin eectio en los proyectos pequenos a corto plazo y, eso si,
contando con recursos humanos de calidad. Los mismos promotores de esta nuea
tendencia reconocen que basan sus experiencias de xito en equipos de desarrollo
pequenos y altamente cualiicados.
4.5.2 Clasificacin en base a su alcance
Mas que una clasiicacin, se trata de una aclaracin del concepto de
metodologa de sotware. Mientras que algunos autores emplean el trmino Metoaotoga
ae .vati.i. para reerirse al conjunto de mtodos que deinen una metodologa, otros se
inclinan por el de Metoaotoga ae De.arrotto ae oftrare. Debido a que el autor que emplea el
primero, ni siquiera menciona el segundo, y iceersa, no se suelen clasiicar en base a
este criterio.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 46
Una metodologa de analisis es un subconjunto -o puede serlo- de una
metodologa de desarrollo de sotware. Lntendemos por metodologa de analisis el
conjunto de mtodos que cubren las ases iniciales del proceso de desarrollo. Ls decir, el
concepto de desarrollo de sotware es mucho mas amplio puesto que abarca al segundo.
4.5.3 Clasificacin en base a la naturaleza del proyecto
3
.
Lste es sin duda el criterio de clasiicacin mas comn y, probablemente, el mas
adecuado. La razn principal que sustenta la airmacin anterior es que no es
coneniente comparar dos metodologas si se encuentran orientadas al desarrollo de
sistemas de naturaleza tecnolgica distinta. As, si bien podramos aplicar o adaptar una
metodologa disenada para el desarrollo de sistemas basados en el paradigma de la
programacin estructurada, a uno basado en el de la orientacin a objetos, no parece
adecuado hacerlo para un sistema basado en conocimiento. Cada naturaleza posible de
proyecto deine una posible amilia de metodologas. Ln este apartado, se trata de
identiicar las amilias de metodologas -al menos las mas representatias- que seran
desarrolladas a lo largo del siguiente captulo.
1. Metodologas orientadas a lujo de inormacin
2. Metodologas orientadas a datos
3. Metodologas orientadas a objetos
4. Metodologas basadas en roles
5. Metodologas agiles de desarrollo
6. Metodologas de dominio especico.
. Metodologas hbridas

3
Ll trmino vatvratea hacer reerencia en este caso a la base tecnolgica o paradigma sobre el que se
desarrolla el proyecto ,orientacin a objetos, programacin declaratia, etc.,.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 47
CAPTULO V FAMILIAS METODOLGICAS
Ll presente captulo tratara de describir las amilias de metodologas que han sido
identiicadas por distintos autores. Para cada una de ellas, se describira someramente la
metodologa mas representatia de la amilia, tomandola como reerencia y estudiando,
siempre desde la perspectia de las posibles aportaciones a la POC, sus rasgos mas
caractersticos.
5.1 METODOLOGAS ORIENTADAS A FLUJO DE INFORMACIN
Ln un sistema inormatico, la inormacin se transorma como un lujo a tras de
un sistema basado en computadora. Ll sistema acepta entrada de distintas ormas, aplica un
hardware, sotware y elementos humanos para transormar la entrada en salida, y produce
una salida en distintas ormas. La entrada puede ser una senal de control transmitida por un
transductor, una serie de nmeros escritos por un operador humano, un paquete de
inormacin transmitido por un enlace a red, o un oluminoso archio de datos
almacenado en memoria secundaria. La transormacin puede comprender una sencilla
comparacin lgica, un complejo algoritmo numrico, o un mtodo de inerencia basado
en regla de un sistema experto. Ln eecto, un modelo de lujo de datos puede aplicarse a
cualquier sistema basado en computadora independientemente del tamano o complejidad.
5.1.1 Metodologa de Anlisis Estructurado y Metodologa de
diseo de Yourdon
(i) Introduccin
Ll analisis estructurado tiene sus orgenes en los ltimos anos de la dcada de los
anos sesenta, primeros de los setenta. Se centra en analisis de los lujos de inormacin
que se dan en un sistema. Ln primera instancia, el analisis estructurado "ervite at
avati.ta covocer vv .i.teva o roce.o ;actiriaaa) ev vva forva tgica , vave;abte at vi.vo tievo qve
roorciova ta ba.e ara a.egvrar qve vo .e ovite vivgvv aetatte ertivevte". Ll objetio principal
del analisis estructurado es organizar las tareas asociadas con la determinacin de
requisitos para obtener la comprensin completa y exacta de una situacin dada.
Ll principal promotor de las bases que undamentan esta metodologa ue 1om
DeMarco, que en su libro .vati.i. .trvctvraao |DeMarco9| estableci los principios
segn los cuales se deba guiar cualquier proceso de analisis de sotware.
o. roavcto. aet avati.i. aebev .er facitvevte vavtevibte., covcretavevte et aocvvevto ae
reqvi.ito. aet .oftrare.
e aebev tratar to. robteva. ae grav tavavo veaiavte atgvv vetoao efectiro ae articiv. a
e.ecificaciv veaiavte voreta. rictoriava. ,a vo .irre DeMarco.
ievre qve .ea o.ibte, .e aebe vtitiar grafico..
e aebe aiferevciar evtre ta. cov.iaeraciove. tgica. o e.evciate., , ta. f.ica. o ae ivtevevtaciv.
t avati.i. aebe a,vaar a airiair to. reqvi.ito. , a aocvvevtar e.a. airi.iove. avte. ae e.ecificar.
Debe .er vv veaio ae .egvivievto , eratvaciv ae ivterface..
Debe .vover vva vvera berravievta ara ta ae.criciv tgica , tactica.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 48
J) Lvolucin
Pese a que DeMarco es sin duda el principal impulsor de esta metodologa,
no es ni mucho menos su nico padre. La propuesta inicial de DeMarco, pese a lo
innoadora y eiciente que result ser para un determinado patrn de proyecto
sotware, presentaba determinados inconenientes para otros tipos de desarrollos.
Dado que el analisis estructurado por aquel entonces era el mejor punto de partida
para desarrollar soluciones metodolgicas para estos otros problemas, se sucedieron
una serie de propuestas y ampliaciones que, a la postre, deriaron en la coneccin de
la metodologa sin duda mas aplicada hasta el momento.
Las carencias mas senaladas era la incapacidad de la notacin propuesta por
DeMarco para la especiicacin de tareas de control y el establecimiento de
secuencias de eentos u otro tipo de restricciones propias de los sistemas en tiempo
real.
Ln 1985, \ard y Mellor |\ard85| proponen con su trvctvrea aeretovevt for
reattive .,.tev. la extensin del analisis estructurado, especialmente de su notacin,
para permitir la contemplacin de sistemas en tiempo real. Posteriormente latley
hizo lo propio con el libro trategie. for reattive .,.tev .ecificatiov |latley88|.
2) Notacin
Uno de las principales aportaciones de DeMarco ue la notacin sobre la que
se construye el analisis estructurado. Principalmente, la diulgacin de los Diagrava.
ae tv;o ae Dato. o DD.. A medida que se iban proponiendo ampliaciones, aparecan
diagramas complementarios al primero que aportaban nueos puntos de ista del
sistema.
Los elementos del lenguaje de modelado empleado en el analisis estructurado
son los siguientes.
a) Diagrama de Ilujo de Datos (DID).
Ll Diagrama de llujo de Datos representa el lujo de la inormacin y las
transormaciones a las que es sometida desde la entrada en el sistema hasta su
salida.
Ll DlD no esta asociado a ningn niel de abstraccin concreto. Las
unidades de proceso que representa ,o bvrbv;a., pueden reerirse a un mdulo muy
especico si el niel de detalle del DlD es alto, o bien al conjunto del sistema
cuando el DlD es de niel 0 ,aiagrava ae covteto,.
Ll DlD original permita los siguientes smbolos graicos:
|viaaae. terva.. Representadas por un recuadro, simbolizan a cualquier
productor o consumidor de inormacin, es decir, lo que en los lenguajes de
modelado orientados a objetos se denomina actor.
Proce.o.. Llemento del sistema que ejecuta una tarea de transormacin de la
inormacin.
tv;o ae Dato.. Representado por una lecha, simboliza la coleccin de datos que
iaja desde un proceso ,o unidad externa, a otro.
.tvacev ae Dato.. Simboliza un repositorio de inormacin sea del tipo que sea.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 49

Iigura 20 Notacin del DID
La mayor cualidad del DlD es su sencillez. No obstante, presenta serias
carencias a la hora de ser empleado para la representacin de los aspectos
dinamicos del sistema, como la secuencia de procesamiento de la inormacin o la
especiicacin de restricciones asociadas a los sistemas en tiempo real.
.vtiaciv ae !ara , Mettor.
Ln respuesta las eidentes carencias de los DlDs para la representacin de
sistemas en tiempo real, \ard y Mellor |\ard85| propusieron la siguiente
ampliacin de su notacin.
tv;o ae Dato. Discontinuo. Para representar lujos de inormacin no
continuos.
Proce.o. ae Covtrot. Ln lugar de procesar datos, procesan senales de control.
tv;o ae Covtrot. Senal de control.
.tvacev ae covtrot. Repositorio de inormacin de control
Proce.o. vvttite.. Para representar arias instancias del mismo proceso dentro del
sistema.
Proceso
Flujo de
informacin
Unidad
Externa
Almacn
de Datos
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 50

Iigura 2J Notacin extendida del DID
b) Diagrama de Ilujo de Control (DIC).
Siguiendo con la lnea propuesta por \ard y Mellor, latley propuso
igualmente la representacin de los lujos de control presentes en el sistema en
orma de lecha discontinua. No obstante, consider que es mas coneniente
representarlo separadamente de los lujos de datos. Como ruto de esa separacin,
surgen los aiagrava. ae ftv;o ae covtrot o DC..
c) Diccionario de Requisitos o Diccionario de Datos.
Se trata de una especiicacin detallada de todos los datos que son
manejados por el sistema. Ll ormato del diccionario de datos no se encuentra
especiicado, y su diseno inal queda supeditado a la opinin del responsable del
proyecto y a las circunstancias del mismo, dado que debido a las dierencias
cualitatias entre los distintos tipos de proyectos, es imposible especiicar un
modelo de diccionario uniersal alido para todos ellos.
d) Narrativa de procesamiento
Parrao asociado al diagrama de lujo de datos que describe alguno de los
procesos que aparecen en el diagrama. Describe la entrada del proceso, el algoritmo
que se aplica y la salida del mismo.
e) Diagrama de 1ransicin de Lstados (D1L)
Los diagramas de transicin de estados se emplean para modelar el
comportamiento de un elemento del sistema mediante un digrao. Ll este tipo de
diagramas se muestran:
Los distintos estados que puede adoptar el objeto de modelado.
Los eentos que pueden llear al objeto de modelado desde un estado a otro.
Proceso
Mltiple
Flujo de
Control
Proceso
de Control
Almacn
de Control
Flujo de
Datos
Discontinuo
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 51
f) 1abla de Activacin de Procesos (1AP)
Se trata de una tabla de decisin en la que se determina cuando un
determinado proceso debe ser o no actiado en base al alor que tengan en ese
momento las ariables del sistema.
g) Diagrama Lntidad-Relacin.
Diagrama que muestra las entidades de un modelo relacional de base de
datos, los atributos de las mismas y las relaciones que comparten.
(ii) Modelo de proceso
1anto el analisis estructurado de DeMarco como el mtodo de \ourdon
|\ourdon9| describen un modelo de proceso en cascada. Las actiidades a cubrir se
an sucediendo una tras otra hasta el inal del proyecto.
(iii) Actividades del ciclo de desarrollo
Llegado a este punto hay que puntualizar que lo que en este captulo se esta
tratando como si uera una metodologa completa no es tal, sino la combinacin de dos
complementarias. Realmente, DeMarco se centr en cubrir las actiidades ligadas a la
ase de analisis del producto. Por otro lado, aparecieron diersos mtodos de diseno, de
entre los cuales aqu destacamos el propuesto por \ourdon |\ourdon9|.
J) Anlisis
La actiidad de analisis se centra en el analisis de los requisitos del sistema.
DeMarco propuso los siguientes pasos a seguir:
a) Creacin de un DID.
Ln primer lugar, se debe desarrollar el denominado DlD niel 0. Se trata
de un diagrama de lujo de datos que muestra el sistema global como una caja
negra, de orma que lo que representa el diagrama son los lujos de entrada y los
lujos de salida del mismo.
Partiendo del DlD niel 0, este se a explotando ,reinando, disminuyendo
paulatinamente el niel de abstraccin. Durante el proceso de etotaciv de los
DlDs se ha de tener cuidado de mantener la coherencia entre los lujos de entrada
y salida del niel n y los del DlD de niel n+J. Ll reinamiento debe comenzar
aislando los procesos, los elementos de datos y los almacenes de datos candidatos a
ser representados en el siguiente niel |Pressman91|.
Ll proceso de identiicacin de procesos, lujos y datos puede llearse a
cabo a partir de la identiicacin de los textos y sustantios de la descripcin del
sistema en lenguaje natural. Lsto, pese a ser un buen reerente orientatio en la
mayora de los casos, no debe aplicarse sistematicamente.
b) Creacin de un modelo de flujo de control
Se trata de coneccionar un diagrama de lujo de control ,DlC, a partir del
resultado del paso anterior. Para ello, se debe partir del diagrama de lujo de datos,
eliminar todos los lujos de datos, y aplicar, en base a la especiicacin del DlC, los
lujos de control conenientes.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 52
c) Lspecificacin del control (CSPLC).
La especiicacin de control del sistema esta compuesta de un diagrama de
transicin de estados y de una tabla de actiacin de procesos. La 1AP especiicara
las condiciones necesarias que se deben dar en el sistema en base a determinadas
condiciones booleanas para que un proceso sea actiado. La 1AP deine una
e.ecificaciv covbivatoria aet covortavievto aet .i.teva |Pressman91|.
d) Lspecificacin del procesamiento (PSPLC).
La especiicacin del procesamiento del sistema no presenta un ormato
determinado. Puede tratarse de una especiicacin textual en lenguaje natural, en
pseudocdigo o lenguaje matematico. Su objetio es desarrollar una especiicacin
tcnica del proceso de cara a que sea empleada como punto de partida en el diseno
del sistema.
e) Llaboracin del diccionario de requisitos.
Aunque este paso aparezca aparentemente aqu, el diccionario de requisitos
se comienza con el arranque del proyecto y se a actualizando y completando a
medida que se an disipando las dudas y asumiendo todos los requisitos del
sistema.
2) Diseo
La actiidad o ase de diseno es cubierta por el mtodo de \ourdon y
Constantine |\ourdon9|, aunque realmente el mtodo de diseno aqu descrito esta
inluido por otros autores como Myers que propusieron ideas paralelas y
complementarias.
Ll primer paso a explicar es la separacin de lujos que hace \ourdon
dentro de un sistema.
Denomina tv;o. ae trav.forvaciv a los comprendidos en el segmento de un
DlD en el que el lujo de datos discurre de orma secuencial a lo largo de uno o
unos pocos caminos |Pressman91|.
Denomina tv;o. ae 1rav.acciv a aquellos que implican biurcaciones en el
camino que siguen los datos desde su entrada en el DlD hasta su salida. Ll centro
de proceso del que parten las biurcaciones del camino se denomina cevtro ae
trav.acciv.
Dependiendo del tipo de lujo con el que se est trabajando, \ourdon
describe mtodos distintos de diseno, siempre partiendo del analisis de requisitos
realizado preiamente, presumiblemente mediante la metodologa de analisis
estructurado. Los dos mtodos son el avati.i. ae trav.forvaciv y el avati.i. ae
trav.acciv.
a) Anlisis de transformacin
Mtodo que partiendo de un diagrama de lujo de datos que presente
estructura de lujo de transormacin, genera un modelo de diseno del sistema que
serira como paso inicial de la implementacin del mismo.
i, Reisin del modelo undamental del sistema
Implica reisar no solo el DlD de niel 0 sino tambin sus documentos
complementarios, como las narratias de procesos y el diccionario de requisitos.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 53
ii, Reisin y reinamiento de los DlDs
Se reisan y reinan los DlDs identiicados durante la ase de analisis.
iii, Clasiicacin del DlD
Se debe clasiicar el DlD en base al patrn de lujo que presente, es decir,
determinar si se trata de un lujo de transormacin, o bien de un lujo de
transaccin.
i, Asilamiento del centro de transormacin.
, Aplicacin del primer niel de actorizacin
La actorizacin da como resultado una estructura de programa en la que los
mdulos de niel superior toman decisiones de niel superior, y los mdulos de
niel inerior ejecutan la mayora del trabajo de entrada, computacional y de
salida |Pressman91|.
i, Aplicacin del segundo niel de actorizacin.
1rata de conertir las transormaciones indiiduales de un DlD en los
mdulos correspondientes de la estructura del programa.
ii, Reinamiento de la estructura resultante mediante medidas y heursticos de
diseno.
b) Anlisis de 1ransaccin
Al igual que en el caso de los DlD que presentan una estructura de lujo de
transormacin, la metodologa de \ourdon aporta mtodos para el analisis de los
que presenten estructura de lujo de transaccin.
Lsencialmente, los primeros pasos son los mismos. Si en el paso 3 descrito
para el analisis de transormacin se determina que se trata de un lujo de analisis
de transaccin, se sustituyen los pasos 4, 5 y 6 por los siguientes.
i, Identiicacin del centro de transaccin y las caractersticas del lujo de cada
camino de accin.
, 1ransormacin del DlD en una estructura adecuada para el procesamiento
de transacciones
i, lactorizacin y reinamiento de las estructuras generadas en los dos pasos
anteriores.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 54
5.2 METODOLOGAS ORIENTADAS A DATOS
Las metodologas orientadas a datos abordan las actiidades deinidas por el
modelo de proceso desde el punto de ista de la estructuracin de la inormacin manejada
por el modelo. Ln muchas areas de aplicacin existe una estructura de inormacin bien
dierenciada y jerarquica. Los datos de entrada, la inormacin almacenada internamente y
los datos de salida pueden presentar estructuras distintas. Lsta amilia de metodologas
utiliza esas estructuras como base para el proceso de desarrollo del sotware |Pressman91|.
Las metodologas orientadas a la estructura de datos representan los requisitos del
sotware enocandose hacia la estructura de datos en lugar de al lujo de datos. Aunque
cada metodologa orientada a la estructura de datos tiene un enoque y notacin distinta,
todas comparten algunas caractersticas en comn:
1. 1odos delegan en el analista la identiicacin de los objetos de inormacin clae
,tambin llamados entidades o tems, y operaciones ,tambin llamadas acciones o
procesos,.
2. 1odos suponen que la estructura de la inormacin es jerarquica.
3. 1odos representan la estructura de la inormacin mediante la secuencia, la
seleccin y la repeticin.
4. 1odos proponen un conjunto de pasos para transormar una estructura de datos
jerarquica en una estructura de programa.
Ll objetio de estas metodologas es transormar la representacin de la
estructura de los datos en la representacin del sotware que debe manejarlos. As, el
primer paso que se debe dar es la modelizacin de los datos. Una ez obtenida la
representacin de la inormacin, se genera el modelo de sotware que debe manejarla
empleando los tres tipos de elementos de control mencionados.
5.2.1 Evolucin
Los comienzos de lo que se denomina 1ecvica. ae avati.i. , ai.evo orievtaaa. a aato.
se dieron a inales de los anos setenta, comienzo de los ochenta. Distintos autores
coincidieron en sus obras en distintas ideas que undamentan este tipo de metodologas
y tcnicas de desarrollo.
Jackson propuso su propio mtodo de analisis y diseno, basado en la elaboracin
-en primer lugar- del modelo de datos del sistema en base a los requisitos del mismo y,
a partir del mismo, la generacin del sotware necesario para tratarlo por medio de los
tres tipos de estructuras de control que deinen la programacin estructurada: bucles,
sentencias de decisin y bloques secuenciales de instrucciones.
J.D. \arnier desarrollo CPL ,Cov.trvcciv gica ae Prograva.,, que
posteriormente deria en DSLD ,De.arrotto ae .i.teva. e.trvctvraao. ev aato. o mtodo de
\arnier-Orr,, una ampliacin del primero que potencia las actiidades relacionadas con
el analisis y el diseno de sistemas |Pressman91|.
5.2.2 El Mtodo de Jackson
(i) Introduccin
Las dos metodologas de desarrollo disenadas por Jackson ueron JSP
,]ac/.ov trvctvrea Progravvivg, y el JSD ,]ac/.ov ,.tev Deretovevt,. JSP es un mtodo
para el diseno de programas como una composicin de procesos secuenciales,
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 55
mientras que el JSD permite especiicar y disenar sistemas con elementos cuyo
comportamiento es maniestable en trminos de secuencias de eentos. JSD aparece
como una extensin eolutia de JSP |Jackson5| que comprende mayores y mas
complejas composiciones de procesos secuenciales y trata los aspectos de
especiicacin e implementacin habituales en el desarrollo de sistemas.
Las metodologas de Jackson se destacaron sobre las entonces existentes en
el momento de su aparicin, debido esto a que durante los comienzos del ciclo de
ida del proyecto, se ocalizaban sobre el dominio del sistema que se pretende
desarrollar, mas que sobre el sistema en s. Ln otras palabras, dan importancia a la
toma de requisitos y al proceso de analisis en general, rente a otras metodologas
segn las cuales la implementacin era el punto de partida del proyecto. As, los
primeros productos que genera la aplicacin de cualquiera de las dos no son sotware
en si, sino su descripcin y cometidos principales. Por otro lado, analizan el sistema
desde un punto de ista dinamico, describiendo las secuencias de eentos entre los
elementos del sistema rente a las istas estaticas de datos sobre las que se
desarrollaban las metodologas existentes en la poca.
Ll analisis de la aportacin de Jackson a la ingeniera del sotware se centrara
en el JSD, dado que contiene al JSP y abarca mayor cobertura de actiidades en el
ciclo de desarrollo del sotware. Para JSD, el dominio del sistema es el mundo real
donde las entidades exhiben comportamientos concurrentes ordenados en el tiempo
que el sistema debe modelar y computar. Lste enoque aproxima la metodologa JSD
de Jackson al paradigma de la orientacin a objetos, donde las entidades JSD se
identiicaran como objetos que interactan por medio de mensajes en lugar de
eentos.
Los principios por los que se rige el JSD son los siguientes:
t ae.arrotto aebe covevar or vva ae.criciv , voaetaao aet vvvao reat, , vo
e.ecificavao, ae.cribievao o e.trvctvravao ta fvvciv qve aebe ae.arrottar et .i.teva. Un
sistema desarrollado con JSD incluye una simulacin explcita del contexto real
del sistema. Ln deinitia, primero se modela el sistema y posteriormente se
implementa. Jackson airma que durante el modelado del mundo real, el
desarrollador debe capturar y comprender el punto de ista del usuario acerca
del contexto del sistema. La abstraccin que debe aplicar el desarrollador debe
ser guiada y contrastada permanentemente con los usuarios del sistema, dado
que ellos son los que mejor conocen el contexto de negocio.
|v voaeto aaecvaao ara rere.evtar et eriaevtevevte oraevaao ev et tievo vvvao reat aebe
tavbiev e.tar oraevaao ev et tievo. Un modelo estatico del mundo real, como por
ejemplo el modelo entidad-relacin no es suiciente para modelar el sistema. Un
medio apropiado es comunicar procesos secuenciales, donde el orden de los
eentos que se producen en el mundo real esta directamente representado en el
modelo del sistema.
t .i.teva aebe .er ivtevevtaao trav.forvavao ta e.ecificaciv ev vv eficievte , covrevievte
cov;vvto ae roce.o., adaptados para ejecutarse sobre el hardware y el sotware
disponible.
(ii) Modelo de proceso
Ll JSD sigue el ciclo de ida clasico o en cascada, donde las actiidades se
suceden secuencialmente una sola ez. Jackson diidi originalmente el proceso de
desarrollar un proyecto de sotware en seis pasos:
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 56
1. Pa.o evtiaaa a acciv, donde mediante un enoque similar al de la orientacin a
objetos |Pressman91| se identiican las entidades y las acciones.
2. Pa.o ae e.trvctvra ae evtiaaa. Se trata de ordenar en el tiempo las acciones que
aectan a cada entidad y se representan mediante diagramas de Jackson.
3. Pa.o aet voaeto iviciat. Se crea un modelo de procesamiento que representa las
entidades y las acciones, y se deinen las conexiones con el mundo real.
4. Pa.o ae ta. fvvciove., donde se especiican las unciones del sistema que
representan a las acciones deinidas durante las ases anteriores.
5. Pa.o ae tevoriaciv aet .i.teva, Se establecen y especiican los aspectos de
planiicacin del proceso.
6. Pa.o ae ivtevevtaciv, donde se especiica el hardware y el sotware como un
diseno.
1. a.e ae voaetaao, donde se describe el mundo real en trminos de eentos,
entidades, roles, ordenacin de eentos y atributos de entidades.
2. a.e ae rea, en la que los procesos del sistema son conigurados dentro de una
red de proceso, partiendo de los modelos de proceso y anadiendo procesos
secundarios para recoger inormacin de entrada al sistema, producir
inormacin de salida y generar inormacin que retroalimente al sistema.
3. a.e ae ivtevevtaciv, donde se considera la planiicacin -de procesos- en el
tiempo, se decide la programacin de procesos e implementacin y se disena la
base de datos -en caso de que exista.
Para analizar JSD se tendra en cuenta la organizacin original de la
metodologa propuesta por Jackson.
(iii) Actividades del ciclo de desarrollo
J) Obtencin de requisitos
Aunque Jackson no emplea el concepto de requisito en si, el primer paso de
los propuestos en su metodologa es organizar la inormacin relatia al mundo real
obtenida por medio de reuniones con el cliente, de orma que esta pueda ser
posteriormente tratada como la entrada del paso de estructura de entidad. Ls decir,
que esta recogiendo requisitos uncionales y distribuyndolos entre entidades y
acciones, mtodo que recuerda a los orientados a la obtencin de requisitos que
proponen las metodologas actuales guiadas por casos de uso ,como RUP, por
ejemplo,. Debido a ello, en el presente documento se interpreta el primer paso del
JSD como parte de la actiidad de obtencin de requisitos.
Pa.o 1. vtiaaa a acciv.
Lsta subactiidad parte de una descripcin del problema en lenguaje natural
recogida por medio de reuniones con el cliente. A partir de la misma, Jackson
propone aplicar la siguiente regla para obtener mecanicamente una identiicacin
inicial de entidades y acciones:
Las entidades se seleccionan examinando todos los nombres de la
descripcin, y las acciones examinando todos los erbos`
La relacin de entidades obtenidas tras la aplicacin de la regla produce un
superconjunto de entidades, entre la cuales se encuentran aquellas que deinen el
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 57
contexto de negocio del sistema. De igual orma, el conjunto de acciones resultante
contiene al conjunto de acciones determinantes para deinir le contexto de negocio
del sistema.
Una ez obtenidos ambas listas, se reinaran despreciando aquellas entidades
y acciones que se consideren intiles o no relacionadas con el problema. 1ras el
rechazo de entidades y acciones candidatas, habra delimitado el ambito del sistema a
desarrollar |Pressman91|.
2) Anlisis
Los pasos segundo y tercero propuestos por Jackson desarrollan tareas
propias de la actiidad de analisis, tal y como la concebimos en el presente contexto
de estudio.
Pa.o 2. .trvctvra ae evtiaaa.
Ln el contexto de JSD, el trmino e.trvctvra ae evtiaaa hace reerencia a la
historia de la entidad considerando el impacto de las acciones a lo largo del
tiempo |Pressman91|. Jackson consider que la ida de una entidad del sistema se
puede representar mostrando las acciones que se aplican sobre ella, organizando
estas acciones bien como secuencia, como parte de una seleccin o como
repeticiones.
Jackson introdujo los aiagrava. ae e.trvctvra para representar la estructura de
las entidades. Son una especiicacin ordenada en el tiempo de las acciones
ejecutadas sobre o por una entidad. Ll diagrama de estructura puede ir
acompanado de un texto explicatio.

Iigura 22 Lstructuras de control
Pa.o . Moaeto iviciat.
Lsta subactiidad comienza a construir una especiicacin del sistema como
un modelo del mundo real |Pressman91|. La especiicacin se crea mediante un
diagrama de especiicacin del sistema ,DLS,. Ll modelo creado se basa en dos
tipos de conexiones entre procesos: coveiv or ftv;o ae aato. y coveiv or rector ae
e.taao.
Secuencia de
acciones
Iteracin de
acciones
Seleccin de
acciones
*
0
0
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 58

Iigura 23 Conexiones de Jackson

La coveiv or ftv;o de datos entre dos procesos se da cuando uno de ellos -el
emisor- transmite un lujo de inormacin y el otro lo recibe. Jackson deine las
posibles operaciones para este tipo de conexiones como:
1. Oeraciove. ara et evi.or
- Oev - .ertvra aet cavat ae covvvicaciv
- !rite - .critvra ae aato. ev et cavat.
- Cto.e - Cierre aet cavat ae covvvicaciv.
2. Oeraciove. ara et recetor
- Oev - .ertvra aet cavat ae covvvicaciv
- Reaa - ectvra ae aato. aet cavat.
- Cto.e - Cierre aet cavat ae covvvicaciv.
Ll lujo de datos se supone como un buer ilimitado con un
comportamiento lIlO. Las lechas indican la direccin del lujo de inormacin,
y el crculo representa el lujo de datos.
Ll ector de estado de un proceso iene dado por el conjunto de estados de
sus ariables locales. La coveiv or rector ae e.taao se da cuando un proceso
inspecciona directamente el ector de estado del otro proceso |Pressman91|.
Jackson propuso la siguiente operacin para representa la lectura del ector de
estado de otro proceso:
Cet.r ;Cet tate 1ector) - ectvra aet rector ae e.taao ae vv roce.o.
Al igual que en la representacin de la conexin por lujo de datos, las lechas
representan la direccin del lujo de inormacin y el rombo el ector de estado.
Los detalles internos de los procesos del modelo se especiican usando lo que
Jackson denomina texto estructurado |Pressman91|. Representa la misma
inormacin que los diagramas de estructura.
3) Diseo
Pa.o ae ta. fvvciove..
Lste paso parte del resultado del anterior, es decir, del diagrama de
especiicacin del sistema, producido durante las actiidades de analisis. La tarea a
llujo de datos
Vector de estado
D
VL
Proceso 0
Proceso 0
Proceso 1
Proceso 1
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 59
acometer es la expansin del diagrama de especiicacin del sistema mediante la
conexin ,por lujo de datos o por ectores de estado, de nueos procesos de
unciones con los procesos ya presentes en el modelo |Pressman91|. Para
Jackson, existen tres tipos de unciones:
1. Las fvvciove. evotraaa. se generan al asignar operaciones al texto
estructurado de un proceso del modelo.
2. Las fvvciove. ivve.ta., que inspeccionan el ector de estado de un proceso
del modelo y produce resultados de salida
3. Las unciones interactias, que inspeccionan el ector de estado de un
proceso del modelo, escriben un lujo de datos que aectan a las acciones
del proceso del modelo e incluyen operaciones para la generacin de
resultados.
Pa.o ae tevoriaciv aet .i.teva.
Durante este paso, el disenador puede establecer las distintas dependencias
existentes entre procesos que se ejecutan de orma paralela. Aqu el disenador
especiica las ligaduras de tiempo impuestas en el sistema |Pressman91|. Ll diseno
producido hasta este punto esta compuesto por un conjunto de procesos
secuenciales comunicados por cualquiera de los dos mtodos contemplados por
la metodologa ,ector de estado o lujo de datos,. Mediante el paso de
temporizacin del sistema es posible especiicar las relaciones de dependencia de
comienzo y in existentes entre estos procesos.
4) Implementacin
Pa.o ae ivtevevtaciv
Ll paso de implementacin propuesto por Jackson describe como debe
transormarse el modelo coneccionado durante los pasos relatios al analisis y al
diseno en cdigo uente, considerando tres posibles construcciones
procedimentales: secuencia, condicin y repeticin. Lstas tres construcciones
establecen la base de la programacin estructurada, y de lo que se llam evfoqve ae
rogravaciv e.trvctvraaa ae ]ac/.ov.
La notacin de la estructura de datos es una eolucin del diagrama de
estructura de Jackson.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 60

Iigura 24 Lstructura de datos
Ln la igura anterior se muestra un ejemplo de cmo se debe interpretar el
diagrama para eectuar el paso a implementacin. La coleccin de datos A esta
compuesta por arias de la estructura de datos B, la cual a su ez incluye una
instancia de C y otra de D. L y l son las dos alternatias posibles dentro de una
ocurrencia de la estructura C.
A
*
0
0
B
C D
L l
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 61
5.3 METODOLOGAS ORIENTADAS A OBJETOS
Ll paradigma de la orientacin a objetos surge a inales de los anos 60, aunque no
llegara a diundirse hasta mediados de los 80. Los lenguajes SIMULA I y SIMULA 6
introdujeron un nueo concepto de sotware en el que por primera ez se manejaba el
concepto de cta.e.
A partir de las experiencias de los lenguajes SIMULA comenzaron a aparecer otras
implementaciones del paradigma, algunas nueas y puras como vatt1at/, otras hbridas
y,o deriadas de la extensin de los lenguajes estructurados como el C-- o el Object
Pascal.
Ll nueo paradigma deina una nuea orma de construir sotware, una nuea
orma de abstraer y, en consecuencia, una nuea orma de disenar. Los cambios, muy
signiicatios, con respecto a la programacin estructurada exigieron la actualizacin de las
metodologas hasta entonces empleadas, comenzando por la imperiosa necesidad de un
nueo lenguaje de modelado que permitiera asociar mtodos o comportamientos a
entidades, en adelante clases. As comenzaron a surgir las primeras metodologas orientadas
a objetos, como el OOSL ,Ob;ect Orievtea oftrare vgeveerivg, de Jacobson |Jacobson92|, el
mtodo de Grady Booch OOAD ,Ob;ectOrievtea .vat,.i. ava De.igv, |Booch93| y OM1 de
Rumbaugh |Rumbaugh91|. Como eolucin de las tres metodologas citadas aparece el
Mtodo Uniicado de Desarrollo de Sotware ,RUP, |Jacobson00| del que se hablara mas
adelante en este captulo.
Ls importante resenar que pese a que el cambio de concepcin sobre el que se
soporta la orientacin a objetos es sin duda el rasgo mas dierencial de estas metodologas,
todas ellas presentan otra caracterstica comn que supone otra aportacin determinante.
lasta la aparicin de la primera metodologa orientada a objetos, las metodologas trataban
como dos problemas distintos y disociados el analisis del dominio del sistema y el diseno de
la solucin sotware. La consecuencia directa de este voav. oeravai es la presencia de un
salto importante entre el analisis y el diseno de la aplicacin |Rumbaugh91|. Por el
contrario, las metodologas orientadas a objetos conciben el diseno como un reinamiento
del producto del analisis, como una eolucin del mismo que, por medio de la abstraccin,
deria en una solucin sotware.
Actualmente, la metodologa orientada a objetos reerente es la anteriormente
citada RUP, que usiona las tres anteriores y trabaja con el lenguaje de modelado UML
|lowler03b| propuesto por OMG.
5.3.1 El Proceso Unificado de desarrollo de software (RUP)
(i) Introduccin
RUP o Ratiovat |vifiea Proce.. ,Proceso uniicado de Rational, es la
metodologa o proceso de desarrollo propuesta por Rational para el desarrollo de
proyectos sotware orientados a objeto.
A raz del incipiente caos metodolgico que se preea a mediados de los
anos 90 con la aparicin de las diersas metodologas orientadas a objetos, todas ellas
con sus correspondientes lenguajes de modelado, surgi la necesidad de uniicar las
lneas de desarrollo metodolgicas. Los tres creadores de las mas signiicatias de
estas metodologas terminaron colaborando en las ilas de Rational Sotware
|Rational|, y de dicha colaboracin surgi el primer borrador del Mtodo Uniicado,
la ersin 0.8 publicada en el OPSLAA 95.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 62
Debido a las presiones interesadas de las empresas desarrolladoras de
herramientas CASL, lo que rapidamente se conirti en un estandar ae facto en el
mercado, ue interenido por OMG que, amparandose en la deinicin de un
estandar para el intercambio de modelos, ormaliz y estandariz la especiicacin
del UML 1.0, lenguaje de modelado empleado por el Mtodo Uniicado de Rational.
1ras arias reisiones, OMG adopt el UML en su ersin 1.1 como uno de sus
estandares oiciales.
Ll mtodo RUP deinido por este peculiar grupo conocido como 1be tbree
.vigo. toma las mejores aportaciones de cada uno de los mtodos propuestos por
los autores, y los uniica en una metodologa nica que ademas emplea como
lenguaje de modelado un estandar de OMG. 1odos los ingredientes estaban puestos
sobre la mesa para que el RUP se conirtiera en la metodologa mas diundida a da
de hoy, siempre dentro del ambito de la orientacin a objetos.
(ii) Modelo de proceso
Ll modelo de proceso que propone RUP es sin duda la caracterstica mas
interesante y dierenciadora. Se trata de un modelo de proceso iteratio e
incremental. Ll proyecto se diide en iteraciones del ciclo de ida, cada una de las
cuales se trata como un miniproyecto en si mismo. Cada miniproyecto o iteracin
produce un incremento en el sistema, y abarca las actiidades propias de un proyecto
en toda regla ,analisis, diseno, implementacin y prueba,. Cada iteracin se construye
sobre el resultado de la iteracin anterior, y se guan por el conjunto de casos de uso
que se decida abarcar en dicha iteracin. Algunas iteraciones no producen un eecto
de aditio, sino de reinamiento o correccin, sobre todo en ases tempranas del
proyecto donde la labor principal del equipo es comprender el sistema a desarrollar y
su contexto de negocio.
Para cada iteracin:
Los desarrolladores identiican y especiican los casos de uso releantes.
Crean un diseno utilizando la arquitectura seleccionada como gua
Implementan el diseno mediante componentes.
Veriican que los componentes satisacen los casos de uso.
Si una iteracin cumple los objetios, el desarrollo contina con la siguiente
iteracin. Cuando por el contrario no se alcanzan los objetios preijados de
antemano, se debe reisar las decisiones preias y probar a aplicar un nueo enoque.
Lste tipo de iteraciones controladas aporta segn RUP |Jacobson00| las siguientes
entajas con respecto al modelo de proceso clasico en casada:
Se reduce el riesgo, dado que el alcance de un error queda delimitado al tamano
de la iteracin en la que se produce ,siempre que ste se detecte al inal de la
misma,, siendo menor su impacto que si se detectara durante la ase de pruebas
propuesta por el modelo de proceso en cascada.
Se reduce el riesgo de desiaciones en la planiicacin total del proyecto, dado
que la identiicacin de los riesgos mas graes se produce durante las ases
tempranas del desarrollo.
Acelera el ritmo de esuerzo del equipo de desarrollo al permitir a los
desarrolladores apreciar los rutos de su trabajo a corto plazo.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 63
La iteracin controlada reconoce la realidad ,a menudo ignorada, de que las
necesidades del usuario y sus correspondientes requisitos no pueden deinirse
completamente al principio del proyecto, sino que se han de reinar, corregir y
completar en iteraciones sucesias.
Para RUP la ida de un sistema se diide en ciclos. Ln cada ciclo se produce
una nuea ersin del producto para los clientes, y consta de cuatro ases: ivicio,
etaboraciv, cov.trvcciv , trav.iciv. Ln cada ase se produciran una o mas iteraciones o
miniproyectos.

Iigura 2S Modelo de proceso RUP
Cada ciclo produce una nuea ersin del sistema, y cada ersin es un
producto preparado para su entrega |Jacobson00|.
J) Iases dentro de un ciclo
1al y como se aprecia en la igura anterior, cada ciclo desarrollado a lo largo
del tiempo se diide en cuatro ases. A tras de una secuencia de modelos se puede
conocer el estado del proyecto y del sistema en cada una de esas ases. Cada una de
las cuatro ases es a su ez descompuesta por los desarrolladores, dando lugar a una
iteracin. Cada inal de cada una de las cuatro ases endra marcado por un hito.
Una iteracin tpica pasa por las cinco actiidades habituales ,requisitos,
analisis, diseno, implementacin y pruebas,
Tiempo
Nacimiento Muerte
.
Los ciclos concluyen con una versin
Tiempo
Inicio Elaboracin Construccin Transicin
Iter
42
Iter
4n
Iter 4n-1
-- -- -- -- -- --
Detalle de un ciclo con sus fases e iteraciones
Iter
41
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 64

Iigura 26 Iases del modelo de proceso RUP
a.e ae ivicio. Durante esta ase se desarrolla una descripcin del producto inal a
partir de una buena idea, y se presenta el analisis de negocio para el producto
|Jacobson00|. A lo largo de la misma se deben establecer las principales
unciones del sistema para los usuarios mas importantes, la arquitectura del
sistema a grandes rasgos y el plan de proyecto con una aproximacin del coste
del producto.
a.e ae etaboraciv. Durante esta ase se especiican en detalle la mayora de los
casos de uso del producto y se disena la arquitectura del sistema. Al inal de esta
ase el responsable del proyecto estara en condiciones de planiicar las
actiidades y estimar los recursos necesarios para llear a cabo el proyecto.
a.e ae cov.trvcciv. Ln esta ase la lnea base de la arquitectura obtenida como
producto durante la ase anterior crece hasta conertirse en el sistema completo.
a.e ae trav.iciv. Cubre el perodo durante el cual el producto se conierte en
ersin beta. Conllea actiidades como la ormacin al cliente, la asistencia,
resolucin de incidencias y clasiicacin de aquellas que justiican una nuea
ersin del producto.
(iii) Actividades del ciclo de desarrollo
J) Obtencin de requisitos
Ll planteamiento del RUP parte del reconocimiento de la diicultad que
entrana la actiidad de tomar de requisitos. Con el objeto de mecanizar dicha tarea
para simpliicar su realizacin, propone aplicar el siguiente mtodo que reparte la
actiidad en cuatro pasos:
1. vvverar to. reqvi.ito. cavaiaato..
2. Covrevaer et covteto aet .i.teva
. Catvrar to. reqvi.ito. fvvciovate.
1. Catvrar to. reqvi.ito. vo fvvciovate..






























Iter
#n
---

---

---

--- Iter
#2
Prueba
Iter
#n-1
--- --- Iter
#1

Implement.
Diseo
Anlisis
Requisitos
Transicin Construccin Elaboracin Inicio Actividades
fundamentales
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 65
a) Lnumerar los requisitos candidatos
Uno de los primeros dilemas a solentar para cada requisito que aparezca en
el sistema es como debe ser clasiicado. Pese a que a priori la naturaleza de un
requisito es eidente ,uncional o no uncional,, a la hora de la erdad es habitual
que surjan dudas razonables que, dependiendo del punto de ista que se aplique,
pueden resultar en una u otra clasiicacin. Debido a que el planteamiento de esta
cuestin puede distraer la labor de toma de requisitos, el mtodo de obtencin de
requisitos propuesto por RUP disocia las actiidades de enumeracin y clasiicacin
de los requisitos del sistema. As, en este primer paso, el objetio es enumerar la
totalidad de los requisitos, independientemente de que estos sean o no de la misma
naturaleza. La lista as ormada no sera estatica, sino que actuara como una cola
cuyos elementos seran extrados a medida que son clasiicados por su naturaleza.
Como ormato de los elementos de la lista, RUP propone el siguiente
conjunto de datos para cada requisito:
Nombre corto Nombre identificativo del requisito
Descripcin Breve descripcin del requisito
Estado Con los siguientes valores discretos:
propuesto
aprobado
incluido
validado
Coste estimado
de
implementacin
En trminos de tipos de recursos y horas persona.
Prioridad Pudiendo tomar los siguientes valores discretos:
crtico
importante
secundario
Nivel de riesgo
asociado a la
implementacin
de la
caracterstica
Pudiendo tomar los siguientes valores discretos:
crtico
significativo
ordinario
Las cuatro ltimas caractersticas de la lista son alores de planiicacin, y
seran considerados, junto con otros aspectos, para estimar el tamano del proyecto y
decidir como diidirlo como una secuencia de iteraciones.
b) Comprender el contexto del sistema
Durante este paso, las personas implicadas en el desarrollo deben asimilar
los conceptos propios del dominio del sistema que han de desarrollar. Los analistas
y el arquitecto principalmente deben adquirir un irme conocimiento del contexto
en el que se emplaza el sistema. Para expresar el contexto de un sistema, RUP
aporta dos aproximaciones complementarias: el modelo de dominio y el modelo de
negocio.
Ll modelo de dominio describe los conceptos importantes del contexto
como objetos de dominio, y enlaza estos objetos unos con otros |Jacobson00|. La
identiicacin y la asignacin de nombres para esos objetos permiten desarrollar un
glosario de trminos que acilitara la comunicacin entre todas las personas
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 66
implicadas en el sistema. Ll objetio del modelo de negocio es describir los
procesos con el objetio de comprenderlos. Ll modelo de negocio especiica qu
procesos de negocio soportara el sistema, y establece las competencias requeridas
en cada proceso: sus trabajadores, su responsabilidades y las operaciones que llean
a cabo.
i, Ll modelo de dominio
Ll modelo de dominio propuesto por RUP captura los tipos mas importantes
de objetos en el contexto del sistema. Los objetos del dominio representan las
cosas que existen o los eentos que suceden en el entorno en el que trabaja el
sistema |Rumbaugh91, Jacobson92|. Los objetos de dominio ,o clases, aparecen
en tres ormas tpicas |Jacobson00|:
Objetos de negocio que representan cosas que se manipulan en el negocio.
Objetos del mundo real y conceptos de los que el sistema debe hacer un
seguimiento, como la aiacin enemiga, misiles, trayectorias.
Sucesos que ocurriran o han ocurrido, como la llegada de un ain, su salida y
la hora de la comida.
Ll medio propuesto por RUP para representar los modelos de dominio son
los diagramas de clases UML. Mediante estos diagramas, se muestra a todas
las personas implicadas en la captura de requisitos las clases del dominio y
cmo se relacionan unas con otras mediante asociaciones |Jacobson00|.
Ll modelo de dominio se realiza en reuniones organizadas por los analistas
del dominio. Puesto que el modelo de dominio slo representara aquellos
objetos de dominio mas importantes, el resto de los cientos de clases candidatas
se recogeran en orma de deiniciones en un glosario de trminos para que
posteriormente sean ealuadas por los analistas. Ls importante recordar que el
objetio del modelo de dominio es acilitar la comprensin del contexto del
sistema, y eitar caer en la tentacin de detallar en exceso ciertas partes del
mismo. Ll modelo de dominio debe contribuir a una comprensin del
problema que se supone que el sistema resuelve en relacin a su contexto
|Jacobson00|, y no especiicar el modo en el cual el sistema resuele dicho
problema, dado que esta tarea es cometido de otras actiidades ,analisis, diseno e
implementacin,.
ii, Ll modelo de negocio
Ll objetio del modelo de negocio es comprender los procesos de negocio
de la organizacin. Se soporta en dos tipos de modelos UML: el modelo de casos
de uso y el modelo de objetos UML.
Un modelo de casos de uso de negocio describe los procesos de negocio
de una empresa en trminos de casos de uso del negocio y actores del negocio
que se corresponden con los procesos de negocio y los clientes, respectiamente
|Jacobson00|. Se describe mediante diagramas de casos de uso UML.
Un modelo de objetos del negocio es un modelo interno a un negocio.
Describe como cada caso de uso de negocio es lleado a cabo por parte de un
conjunto de trabajadores que utilizan un conjunto de entidades del negocio y de
unidades de trabajo |Jacobson00|. Cada caso de uso de un negocio puede
mostrarse mediante diagramas de interaccin y diagramas de actiidad. Cada
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 67
trabajador, entidad del negocio y unidad de trabajo puede participar en la
realizacin de mas de un caso de uso del negocio.
Ll modelo de negocio se desarrolla en dos pasos. Ln primer lugar, los
modeladores deben coneccionar un modelo de casos de uso del negocio que
identiique los actores del negocio y los casos de uso del negocio que utilicen
dichos actores. 1ras esto, y partiendo de este modelo de casos de uso, se
desarrollara un modelo de objetos del negocio compuesto por trabajadores,
entidades del negocio y unidades de trabajo que juntos realizan los casos de uso
del negocio. A estos objetos se les asocian las reglas de negocio, y otras normas
impuestas por el negocio.
c) Captura de requisitos funcionales
A partir de la relacin de requisitos obtenida en el primer paso, y dirigido
por el modelo o modelos obtenidos en el segundo, se extraen los casos de uso del
sistema. Los casos de uso capturan tanto los requisitos uncionales, como los no
uncionales que son especicos del caso de uso. Partiendo del modelo de negocio
como entrada, se aplica la siguiente tcnica para obtener los casos de uso del
sistema:
1. Se identiica un actor por cada trabajador y por cada actor del negocio ,es decir,
por cada cliente, que se conertira en un usuario del sistema. Cada trabajador ,y
cada actor del negocio, que aya a ser usuario del sistema de inormacin
requerira un soporte por parte del mismo. Ll soporte necesario se determina
tratando cada uno de los trabajadores, uno detras del otro.
2. Para el trabajador seleccionado, se identiican todas las realizaciones de los
casos de uso de negocio dierentes en los que participa. Ll trabajador cumple un
rol en cada una,
3. Para cada rol del trabajador o actor de negocio, al que se ha identiicado ya su
actor en el sistema ,paso 1,, y cada caso de uso de negocio en el que participa,
se genera un caso de uso.
Una ez aplicado este algoritmo a todos los trabajadores o actores del
negocio identiicados, se tiene el superconjunto de los casos de uso potenciales del
sistema. Los analistas pueden detallar y ajustar despus estos casos de uso, y deben
decidir cuantas y cuales de las tareas de los trabajadores o de los actores del sistema
deben ser automatizadas mediante sistemas de inormacin ,en orma de casos de
uso, y reorganizar los casos de uso para que se ajusten mejor a las necesidades de
los actores. No todas las tareas tienen porqu ser adecuadas para ser automatizadas.
A estas alturas, la mayora de los requisitos uncionales y no uncionales
estan comprendidos en alguno de los casos de uso identiicados. Algunos requisitos
no pueden asociarse a ningn caso de uso en concreto, y se denominan requisitos
adicionales.
d) Captura de requisitos no funcionales
Se recogen como requisitos adicionales o casos de uso concretos ,para
requisitos especicos de un caso de uso,. 1ras el proceso de captura de los
requisitos uncionales, slo quedaran por recoger los denominados adicionales, es
decir, los que no pueden asociarse a ningn caso de uso en concreto. Algunos
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 68
ejemplos son el rendimiento, las interaces
4
y los requisitos de diseno sico
5
, as
como las restricciones arquitectnicas, de diseno y de implementacin
|Jacobson00|. Se capturan con una lista de requisitos y se utilizan posteriormente
durante el analisis y el diseno junto al modelo de casos de uso.
2) Anlisis
RUP e la actiidad de analisis como un reinamiento y estructuracin de los
requisitos capturados durante la actiidad anterior. Para ello, parte del producto
obtenido, el modelo de casos de uso, que no en ano se considera uno de los tres
pilares basicos de toda la metodologa. Ll objetio del analisis es conseguir una
comprensin mas precisa de los requisitos y una descripcin de los mismos que sea
acil de mantener |Jacobson00|.
a) Ll modelo de anlisis en RUP
Ll modelo de analisis de RUP se sire de distintos arteactos para
representar el sistema una ez reinados y estructurados los requisitos. 1odos ellos
basan su representacin en los medios que orece el UML.
i, Clase de analisis
Representa una abstraccin de una o arias clases y,o subsistemas del diseno
del sistema. Basicamente, se centra en el tratamiento de los requisitos
uncionales, y pospone los no uncionales. Ll niel de abstraccin esta muy por
encima de lo que seran las clases del diseno, manejando conceptos propios del
contexto del sistema que ayuden a comprenderlo. Su comportamiento se deine
mediante responsabilidades en lugar de mtodos de implementacin, y sus
atributos son tambin de muy alto niel y de tipos conceptuales y reconocibles
en el dominio del problema. Pueden ser clases de interaz, de control o de
entidad.
ii, Realizacin de caso de uso
Ls una colaboracin dentro del modelo de analisis que describe como se
llea a cabo y se ejecuta un caso de uso determinado en trminos de las clases
del analisis y de sus objetos del analisis en interaccin |Jacobson00|. Proporciona
por tanto una traza directa hacia un caso de uso concreto del modelo de casos
de uso.
b) Metodo de anlisis en RUP
RUP propone la siguiente secuencia de acciones para llear a cabo el analisis
del sistema.

4
Se reiere a interaces del sistema, no a interaces de usuario. Un requisito de interaz especiica la interaz
con un elemento externo con el cual debe interactuar el sistema, o que establece restricciones condicionantes
en ormatos, tiempos, u otros actores de releancia en esa interaccin |Jacobson00|.
5
Lspeciica una caracterstica sica que debe poseer un sistema, como su material, orma, tamano o peso.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 69
i, Analisis de la arquitectura
Los arquitectos comienzan la creacin del modelo de analisis identiicando
los paquetes de analisis principales, las clases de entidad eidentes y los
requisitos comunes. Consta de los siguientes pasos:
a. aevtificaciv ae to. aqvete. ae avati.i..
Proporcionan un medio para organizar el modelo de analisis en piezas mas
pequenas y mas manejables. RUP propone un mtodo directo para identiicar
los paquetes del analisis, consistente en asignar la mayor parte de un cierto
nmero de casos de uso a un paquete concreto y despus realizar la
uncionalidad correspondiente dentro de ese paquete. Lntre las asignaciones
adecuadas` de casos de uso a un paquete se tiene:
Los casos de uso requeridos para dar soporte a un determinado proceso de
negocio.
Los casos de uso para dar soporte a un determinado actor del sistema
Los casos de uso que estn relacionados mediante relaciones de
generalizacin y de extensin.
b. aevtificaciv ae ta. cta.e. ae evtiaaa obria..
La mayora de las clases se identiican al crear las realizaciones de los casos de
uso. Ll producto de esta actiidad se debe limitar a un esbozo inicial de las
clases signiicatias para la arquitectura, eitando caer en el error de detallarlas
demasiado. Las agregaciones y asociaciones entre las clases del dominio en el
modelo de dominio ,o entre entidades del negocio en el modelo de negocio,
pueden utilizarse para identiicar un conjunto proisional de asociaciones entre
las correspondientes clases de entidad.
c. aevtificaciv ae reqvi.ito. e.eciate. covvve.
Los requisitos especiales son aquellos que aparecen durante e analisis y que es
necesario anotar de orma que pueda ser tratado adecuadamente en las
subsiguientes actiidades de diseno e implementacin. Por ejemplo, pueden ser
limitaciones o restricciones de persistencia, distribucin y concurrencia,
caractersticas de seguridad, tolerancia a allos o gestin de transacciones.
ii, Analizar un caso de uso.
Una ez se tiene el analisis de la arquitectura, se debe analizar el sistema
desde los casos de uso identiicados durante la obtencin de requisitos. Para
cada caso de uso, se identiican las clases del analisis cuyos objetos son
necesarios para llear a cabo el lujo de sucesos del caso de uso, se distribuye el
comportamiento del caso de uso entre los objetos del analisis y se capturan los
requisitos especiales sobre la realizacin del caso de uso.
a. aevtificaciv ae ta. cta.e. aet avati.i..
Ln este paso se identiican las clases de control, entidad e interaz necesarias
para realizar los casos de uso. Se esbozan sus nombres, responsabilidades,
atributos y relaciones. RUP propone el siguiente conjunto de normas para la
identiicacin de las clases de analisis:
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 70
Identiicar las clases, mediante el estudio en detalle de la descripcin del
caso de uso y de cualquier modelo del dominio que se tenga, y despus
considerar qu inormacin debe utilizarse y manipularse en la realizacin
del caso de uso.
Identiicar la clase de interaz central para cada actor humano, y dejar que
esta clase represente la entana principal de usuario con el cual interacta
el actor.
Identiicar una clase de interaz primitia para cada clase de entidad
encontrada con anterioridad. Lstas clases representan objetos lgicos con
los cuales interacta el actor humano en la interaz de usuario durante el
caso de uso.
Identiicar una clase de interaz central para cada actor que sea un sistema
externo y dejar que esta clase represente la interaz de comunicacin.
Identiicar una clase de control responsable del tratamiento del control y de
la coordinacin de la realizacin del caso de uso, y despus reinar esta
clase de control de acuerdo a los requisitos del caso de uso. Ln algunos
casos el control se encapsula mejor dentro de una clase de interaz,
especialmente si el actor maneja gran parte del control.
b. De.criciv ae ivteracciove. evtre ob;eto. aet avati.i..
Partiendo del esbozo de clases necesarias para realizar el caso de uso,
debemos describir cmo interactan sus correspondientes objetos del analisis.
Para ello se emplean diagramas de colaboracin UML que contienen las
instancias de actores participantes, los objetos del analisis, y sus enlaces. RUP
propone las siguientes normas o consideraciones a seguir para desarrollar esta
actiidad:
Ll caso de uso debe ser inocado mediante un mensaje proeniente de una
instancia de un actor sobre un objeto interaz.
Cada clase de analisis identiicada en el paso anterior debe aparecer al
menos en algn diagrama de colaboracin. Ln caso de no ser as, se trata
de una clase superlua y debe ser eliminada, dado que no aporta nada al
sistema al no participar en ninguna realizacin de ningn caso de uso.
Los mensajes no relejan operaciones ,dado que se trata de la ase de
analisis,, sino el propsito del objeto inocante. .te ro.ito veae aar
origev a vva re.ov.abitiaaa ev et ob;eto ivrocaao.
Los enlaces en el diagrama generalmente seran instancias de asociaciones
entre clases del analisis
Ll diagrama de colaboracin debe tratar todas las relaciones del caso de uso
que se esta realizando.
c. Catvra ae reqvi.ito. e.eciate..
Ln este paso se recogen todos requisitos de caso de uso que se identiican en
el analisis pero que deberan tratarse en el diseno y en la implementacin, como
los requisitos no uncionales.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 71
iii, Analizar una clase.
1ras el analisis de todos los casos de uso, se debe procede a analizar todas la
clases de analisis que se han identiicado una ez alcanzado este punto de la
actiidad. Los objetios a cubrir al analizar una clase son identiicar y mantener
las responsabilidades de una clase de analisis, sus atributos y relaciones, y
capturar los requisitos especiales sobre la realizacin de la clase del analisis. RUP
propone el siguiente procedimiento:
a. aevtificar re.ov.abitiaaae..
La responsabilidades de una clase pueden recopilarse combinando todos los
roles que cumple esa clase en dierentes realizaciones de caso de uso.
b. aevtificaciv ae atribvto..
Al igual que las responsabilidades, los atributos se deducen de los distintos
casos de uso en donde apareci la clase. Ll identiicador del atributo debe ser un
nombre, y su tipo conceptual y no determinado, de orma que se mantenga
independiente del entorno de implementacin. No obstante, se debe tratar de
limitar el conjunto de tipos de atributos mediante la reutilizacin de los mismos
conceptos siempre que sea posible.
c. aevtificaciv ae a.ociaciove. , agregaciove..
Para ello, RUP proponer partir de los diagramas de colaboracin, dado que
los enlaces que contienen suelen ser instancias de asociaciones entre sus
correspondientes clases.
a. aevtificaciv ae geveratiaciove..
Lstas deben mantenerse a un niel muy alto y conceptual, dado que su
objetio es acilitar la comprensin del analisis.
e. Catvra ae reqvi.ito. e.eciate..
Al igual que durante el analisis del caso de uso, en este paso se recogen todos
requisitos de caso de uso que se identiican en el analisis pero que deberan
tratarse en el diseno y en la implementacin.
i, Analizar un paquete
Las maximas que se debe seguir son garantizar la independencia del paquete
de los demas en la medida de lo posible, que el paquete de analisis cumpla su
objetio de realizar algunas de las clases del dominio o casos de uso, y describir
las dependencias de orma que pueda estimarse el eecto de los cambios uturos.
3) Diseo
Durante la actiidad de diseno, se modela el sistema y se deine su orma
incluida su arquitectura para que soporte todos los requisitos. Ll diseno permite
adquirir una comprensin prounda de los aspectos relacionados con los requisitos
no uncionales y restricciones relacionadas con los lenguajes de programacin,
componentes reutilizables, sistemas operatios, tecnologas de distribucin y
concurrencia, tecnologas de interaz de usuario, tecnologas de gestin de
transacciones, etc. Crea una entrada apropiada para las actiidades de
implementacin y descompone los trabajos de implementacin en partes mas
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 72
manejables separadas por interaces deinidas ,subsistemas de diseno,. Ls importante
subrayar la dependencia del diseno con el entorno de desarrollo y produccin donde
se a a construir e implantar el sistema. Aparecen nueas restricciones impuestas por
los parametros tecnolgicos que pueden llear a transormaciones del modelo de
analisis. Por ejemplo, si trabajamos con un lenguaje de programacin que no admite
herencia, las generalizaciones deducidas durante el analisis deberan ser transormadas
en otro tipo de relaciones.
lablando en trminos del ciclo de ida de un proyecto RUP, el diseno se
encuentra localizado entre el inal de la etapa de elaboracin y los inicios de la etapa
de construccin. Ln consecuencia, el modelo de diseno se unde con la
implementacin, siendo relatiamente sencillo y habitual mantenerlo coherente a lo
largo de todo el ciclo de ida si se emplean herramientas de ingeniera de ida y uelta.
La actiidad de diseno produce dos modelos como resultado de su
aplicacin, el modelo de diseno y el modelo de despliegue.
4) Ll modelo de diseo
Ls el principal resultado, y se esuerza en conserar la estructura del sistema
propuesta por el modelo de analisis. Ll modelo de diseno, que serira como esquema
para la implementacin del sistema, incluye los siguientes elementos:
Subsistema del diseno y subsistemas de sericio y sus dependencias, interaces y
contenidos.
Clases del diseno, incluyendo las clases actias, y sus operaciones, atributos y
requisitos de implementacin. Algunas de las clases releantes para la
arquitectura se obtienen directamente de las clases de analisis releantes para la
arquitectura. Ln general, las clases de analisis se utilizan como especiicaciones
para obtener las clases de diseno
Realizaciones de casos de uso-diseno, que describen como se disenan los casos
de uso en trminos de colaboraciones dentro del modelo de diseno. Lstas se
obtienen partiendo de las realizaciones de casos de uso-analisis como
especiicaciones.
La ista arquitectnica del modelo de diseno, incluyendo sus elementos
signiicatios de cara a la arquitectura.
S) Ll modelo de despliegue
Ll modelo de despliegue es un modelo de objetos que describe la distribucin
sica del sistema en trminos de cmo se distribuye la uncionalidad entre los nodos
de cmputo |Jacobson00|. Se deine entonces en trminos de nodos o unidades de
computo ,normalmente procesadores o dispositios hardware en general,, y sus
relaciones que representan los medios de comunicacin entre los nodos, como
Internet, bus, etc.
Ll modelo de despliegue puede describir arias coniguraciones distintas. As,
es posible que se deina una coniguracin de pruebas, una de preproduccin y otra
de produccin. La uncionalidad de un nodo iene deinida por la de los
componentes que se distribuyen sobre ese nodo.
Ln deinitia, el modelo de despliegue representa la correspondencia entre la
arquitectura sotware y la arquitectura hardware del sistema.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 73
a) Metodo de diseo
Una ez deinidos los dos modelos resultantes de la actiidad de diseno, se
puede describir el mtodo que propone RUP para esta actiidad. A grandes rasgos,
el mtodo diide la actiidad en cuatro pasos o subactiidades: el diseno de la
arquitectura, el diseno de los casos de uso, el diseno de clases y el diseno de
subsistemas.
i, Diseno de arquitectura.
Ll objetio de esta subactiidad es esbozar los modelos de diseno y
despliegue y su arquitectura mediante la identiicacin de los siguientes
elementos |Jacobson00|:
a. ^oao. , .v. covfigvraciove. ae rea.
Durante esta actiidad es cuando se identiican y deinen no solo los nodos,
sino tambin su capacidad en trminos de potencia, los tipos de conexiones que
deben interconectarlos, sus protocolos y caractersticas ,ancho de banda,
disponibilidad, calidad,, tolerancia a allos, migracin de procesos y otros
procesos redundantes.
b. vb.i.teva. , .v. ivterface..
Lsta subactiidad pretende organizar el modelo de diseno en piezas
manejables, aislando al mismo tiempo dentro bajo el prisma de subsistema a
piezas de cdigo ya desarrolladas con anterioridad y reutilizadas que deben ser
manejadas como elementos aislados. Ll orden propuesto por RUP para llear a
cabo esta subactiidad deine la siguiente secuencia de pasos:
a. Identiicar los subsistemas de aplicacin, es decir, los correspondientes a las
capas especica y general de la aplicacin.
b. Identiicar los subsistemas intermedios y de sotware del sistema, que
constituyen los cimientos del sistema.
c. Deinir las dependencias entre subsistemas
d. Identiicar los interaces entre subsistemas.
c. Cta.e. aet ai.evo .igvificatira. ara ta arqvitectvra.
RUP aporta una serie de recomendaciones para seguir esta actiidad.
Basicamente, consiste en un reinamiento de las especiicaciones de stas clases
que ueron obtenidas durante la actiidad de analisis, pero sin llegar a detallar en
proundidad las clases, dado que sta descripcin se era aectada durante el
diseno de los casos de uso.
a. Mecavi.vo. ae ai.evo geverico. qve tratav reqvi.ito. covvve..
Por ejemplo, los requisitos especiales sobre persistencia, distribucin,
rendimiento, etc.
ii, Diseno de casos de uso
Durante el diseno de cada caso de uso identiicado en el analisis, se
identiican las clases del diseno y,o subsistemas cuyas instancias son necesarias
para llear a cabo el lujo de sucesos del caso de uso, se distribuye el
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 74
comportamiento del caso de uso entre los objetos del diseno, se deinen los
requisitos sobre las operaciones de las clases del diseno y los subsistemas y sus
interaces, y se capturan los requisitos de implementacin del caso de uso.
a. aevtificaciv ae ta. cta.e. aet ai.evo articiavte..
Se identiican las clases del diseno que se necesitan para realizar el caso de
uso. Se estudian las clases del analisis que participan en la correspondiente
realizacin del caso de uso-analisis, y se identiican las clases del diseno que
poseen una traza hacia esas clases del analisis. Se estudian tambin los requisitos
especiales asociados al caso de uso-analisis. Ll resultado de esta subactiidad
debe ser la identiicacin de todas las clases necesarias para el caso de uso.
b. De.criciv ae ta. ivteracciove. evtre ob;eto. aet ai.evo
Se realiza por medio de diagramas de secuencia UML que contienen las
instancias de los actores, los objetos del diseno y las transmisiones de mensajes
entre estos que participan en el caso de uso. Como cabe esperar a estas alturas,
esta actiidad consiste en un reinamiento de las interacciones identiicadas
durante el analisis para este mismo caso de uso y sus objetos de analisis, slo que
partiendo, como es eidente, de sus correspondientes objetos de diseno.
c. aevtificaciv ae .vb.i.teva. e ivterface. articiavte..
La coneniencia de aplicar esta actiidad se alora en base a la complejidad
del sistema, a su tamano y, en deinitia, a la necesidad de diidirlo en
subsistemas para clariicar y repartir las responsabilidades entre piezas que
contienen clases con cometidos comunes.
a. De.criciv ae ta. ivteracciove. evtre .vb.i.teva..
Al igual que como se hizo con las clases, pero con los subsistemas
identiicados durante el paso anterior.
e. Catvra ae reqvi.ito. ae ivtevevtaciv.
Se incluyen en el caso de uso todos los requisitos no uncionales identiicados
durante el diseno que deberan tratarse durante la actiidad de implementacin.
b) Diseo de una clase
La actiidad de diseno de una clase es dependiente del tipo de clase con la
que se est tratando. Ln uncin de si se trata de una clase de interaz, una clase de
control o una clase de entidad, RUP aporta una serie de recomendaciones para su
deinicin en detalle. Los pasos comunes, siempre partiendo de la correspondiente
especiicacin de la clase de analisis obtenida durante esta actiidad, son:
a. aevtificar ta. oeraciove. ae ta cta.e
Se realizara mediante la sintaxis del lenguaje de programacin, manteniendo
la traza con las correspondientes clases del analisis.
b. aevtificar to. atribvto. ae ta cta.e
De nueo manteniendo la coherencia y trazabilidad con la correspondiente
clase del analisis. Los tipos de los atributos estaran restringidos a los tipos del
lenguaje de programacin, establecindose paulatinamente un mapeo entre los
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 75
tipos conceptuales` deinidos durante el analisis y los tipos del lenguaje de
programacin objeto.
c. aevtificar a.ociaciove. , agregaciove. ae ta cta.e
Lstas se deduciran inicialmente de los diagramas de interaccin obtenidos
durante el diseno del caso de uso. Se reina la multiplicidad y la naegabilidad de
las relaciones que ya haban sido identiicadas durante el analisis.
a. aevtificar ta. geveratiaciove. .irrievao.e ae ta .evavtica aefiviaa or et tevgva;e ae
rogravaciv.
Ln ciertas ocasiones la generalizaciones deducidas durante el analisis no
podran ser implementadas debido a restricciones del lenguaje, por lo que
durante la presente subactiidad deberan ser transormadas en otro patrn de
relaciones que a eectos practicos sea igualmente consistente con el modelo.
e. De.criciv ae to. vetoao.
Descripcin por medio del lenguaje natural o bien de pseudocdigo que,
posteriormente, sera asimilado por la implementacin a modo de comentario.
f. De.criciv ae to. e.taao.
Ll estado de una clase iene dado por la combinacin de los alores que
tienen sus atributos en un momento dado. Ls necesario describir la semantica
del estado de aquellos objetos cuyo estado deine en comportamiento del
sistema en un punto determinado de su uncionamiento. Para ello, RUP se
apoya en el diagrama de estados UML.
g. 1ratavievto ae to. reqvi.ito. e.eciate.
Ln este momento se tratara todo requisito que no haya sido considerado
hasta ahora.
c) Diseo de subsistema
Ll diseno de subsistemas debe garantizar la maxima independencia posible
del subsistema de los otros subsistemas y,o de sus interaces. As mismo, se
enatiza el correcto diseno de sus interaces, y que el subsistema cumple su
propsito en tanto en cuanto orece una realizacin correcta de las operaciones tal
y como las deinen las interaces que proporciona.
Deben deinirse y mantenerse las dependencias entre los distintos
subsistemas del modelo cuando los elementos de uno estan relacionados con los
elementos de otro subsistema distinto, y procurar mantener la interaz de un
subsistema con los otros subsistemas.
6) Implementacin
La actiidad de implementacin parte del resultado del diseno para
implementar el sistema en trminos de componentes, entendiendo como tales
icheros de cdigo uente, scripts, icheros binarios, ejecutables y otras piezas
susceptibles de ormar parte del entregable inal. Las tareas mas importantes a
desarrollar durante la implementacin son la planiicacin de las integraciones
necesarias en cada iteracin, la distribucin del sistema entre los distintos nodos, la
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 76
implementacin de clases y subsistemas y la prueba unitaria de todos los
componentes, su integracin, compilacin y enlazado.
a) Ll Modelo de implementacin
Describe tanto los elementos del modelo de diseno, como las clases, se
implementan en trminos de componentes. Organiza los componentes de acuerdo
con los mecanismos de estructuracin y modularizacin disponibles en el entorno
de de implementacin y en el lenguaje o lenguajes de programacin.
b) Metodo de implementacin
Ll mtodo de implementacin propuesto por RUP organiza esta actiidad
mediante un algoritmo de cinco pasos que parte de la implementacin de las clases
que deinen la arquitectura del sistema, dado que sobre ellas se implementara
despus todo lo demas.
i, Implementacin de la arquitectura
Se esboza el modelo de implementacin y su arquitectura mediante la
identiicacin de los componentes arquitectnicos y su asignacin a nodos
computacionales dentro del sistema sico.
ii, Plan de integracin del sistema
Se crea un plan de integracin del sistema que establece las integraciones que
se produciran durante la construccin y los objetios que deben cubrir cada una
de estas integraciones. Cada integracin se construye sobre la integracin
anterior. Los objetios pueden establecerse en trminos de casos de uso,
asignando un determinado conjunto de casos de uso a cada integracin, y no
producindose sta hasta que dichos casos de uso hayan sido ya implementados.
iii, Implementacin de subsistemas
Se implementa el subsistema asegurando la cobertura de los requisitos
recogidos en el modelo de diseno para este subsistema. Durante la
implementacin de subsistema se han de mantener los contenidos tal y como se
han deinido en el modelo de diseno, as como sus interaces, dado que de no
hacerlo de esta manera, resulta imposible paralelizar la implementacin de
mdulos con equipos distintos, puesto que a la hora de integrarlos se produciran
errores debido a la inconsistencia de los mensajes que se intercambian.
i, Implementacin de clases
Para cada subsistema, se han de implementar las clases que contiene tal y
como se deinen en el modelo de diseno. De nueo se enatiza la importancia
que tiene el mantenimiento de la interaz de la clase.
, Pruebas unitarias
Cada componente implementado debe ser probado indiidualmente antes de
ser integrado. Por un lado, se comprobara el comportamiento del componente
desde uera, mediante pruebas de especiicacin o caja negra. Por otro, se
realizara pruebas de estructura o de caja blanca, que eriican la implementacin
interna del componente.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 77
7) Pruebas
Durante la actiidad de prueba se eriica el resultado de la implementacin
probando cada construccin, incluyendo tanto construcciones internas como
intermedias, as como las ersiones inales del sistema a ser entregadas al cliente
|Jacobson00|. Los objetios de las pruebas son planiicar las pruebas necesarias en
cada iteracin, disenar e implantar las pruebas creando los casos de prueba que
especiican qu probar y realizar dichas pruebas manejando los resultados
sistematicamente. La actiidad de pruebas en RUP se extiende practicamente a lo
largo de toda la ida del proyecto, dado que a medida que se a alcanzando una
comprensin alta del contexto del sistema durante el analisis, se pueden ir disenando
los casos de prueba que eriicaran el correcto uncionamiento del sistema una ez
est construido. As, durante la implementacin se realizan pruebas unitarias de los
componentes que se an construyendo nada mas terminarlos.
a) Modelo de pruebas
Describe principalmente como se prueban los componentes ejecutables en
el modelo de implementacin con pruebas de integracin y de sistema. Puede
tambin describir como se prueban ciertos aspectos especicos del sistema, como
por ejemplo, la usabilidad de su interaz, o la eectiidad del manual de usuario. Se
compone de una coleccin de:
i, Casos de prueba.
Un caso de prueba especiica una orma de probar el sistema, incluyendo la
entrada o el resultado con la que se ha de probar y las condiciones bajo las que
ha de probarse. Los casos de prueba comunes son los que especiican como
probar un caso de uso o un escenario concreto de un caso de uso.
ii, Procedimientos de prueba.
Lspeciica como realizar uno o arios casos de prueba o partes de estos. Un
mismo procedimiento puede ser aplicado a arios casos de prueba.
iii, Componentes de prueba.
Un componente de prueba automatiza uno o arios procedimientos de
prueba o partes de ellos. Ln el caso del lenguaje jaa, por ejemplo, existen
distintos fraveror/. bastante populares como ]|vit |JUnit| y Cactv. |Cactus| de
]a/arta, que acilitan la construccin de componentes de prueba.
b) Metodo de pruebas
Ll principal objetio de mtodo propuesto por RUP para probar el sistema
es naturalmente realizar y ealuar las pruebas como se describe en el modelo de
pruebas. Los responsables de las pruebas ,Ingenieros de pruebas en RUP, inician
esta tarea planiicando el esuerzo de prueba en cada iteracin. La secuencia de
acciones que RUP propone como mtodo consiste en:
i, Planiicar prueba
Planiica los esuerzos de prueba en una iteracin describiendo una estrategia
de prueba, estimando los requisitos para el esuerzo de la prueba ,recursos
humanos, sistemas necesarios, etc., y planiicando el esuerzo de la prueba.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 78
ii, Disenar prueba
Se trata de identiicar y describir los casos de prueba para cada construccin,
e identiicar y estructurar los procedimientos de prueba especiicando cmo
realizar los casos de prueba.
iii, Implementar la prueba
Ll propsito de implementar la prueba es automatizar en la medida de lo
posible los procedimientos de prueba creando componentes de prueba, algo que
no siempre es posible o incluso rentable, dado que no todos los procedimientos
de prueba pueden ser automatizados.
i, Realizar pruebas de integracin
Se realizan las pruebas de integracin necesarias para cada una de las
construcciones creadas en una iteracin y se recopilan los resultados de las
pruebas.
, Realizar pruebas del sistema
Se realizan las pruebas del sistema, que pueden comenzar cuando las pruebas
de integracin indiquen que el sistema satisace los objetios de calidad de
integracin ijado en el plan de prueba de la iteracin actual.
i, Laluar prueba
Se ealan los resultados de la prueba comparado los resultados obtenidos
con los objetios esbozados en el plan de prueba. Valindose de mtricas, se
eala la calidad del sotware y que cantidad de pruebas es necesario hacer. Las
dos mtricas imprescindibles segn RUP son:
Complecin de la prueba, obtenida a partir de la cobertura de los casos de
prueba y de la cobertura de los componentes probados. Lsta mtrica
indica el porcentaje de casos de prueba que han sido ejecutados y el
porcentaje de cdigo que ha sido probado.
liabilidad, la cual se basa en el analisis de las tendencias en los deectos
detectados y en las tendencias en las pruebas que se ejecutan con el
resultado esperado.
La iabilidad del sistema se aproxima por medio de diagramas sobre las
tendencias de los deectos, representando los tipos especicos de deectos a lo
largo del tiempo. Las tendencias de los deectos siguen a menudo patrones que
se repiten en arios proyectos. Basandose en el analisis de las tendencias de los
deectos, los disenadores de pruebas pueden sugerir acciones como realizar
pruebas adicionales para localizar mas deectos, relajar el criterio de las pruebas
o aislar partes del sistema que parecen tener un niel de calidad aceptable y
entregarlas como resultados de la iteracin actual.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 79
5.4 METODOLOGAS BASADAS EN ROLES
Desde la aparicin del paradigma de la orientacin a objetos, y con l, las primeras
metodologas que uniicaban todo el proceso de desarrollo ,analisis y diseno,, muchos
autores se lanzaron a desarrollar propuestas de mtodos para el desarrollo de proyectos que
siguieran esta ilosoa. 1odas ellas se basan en la abstraccin de cta.e como element
atmico de sus construcciones. La dicotoma clase,objeto, en cualquiera de sus ormas y
notaciones, aparece, pues, omnipresente en la literatura sobre Programacin Orientada a
Objetos. Sin embargo, no siempre es posible modelar un dominio del mundo real en base
nicamente a clases y objetos |Deis96|.
Los modelos de roles entienden el concepto de clase no como un elemento
atmico, sino como una implementacin de otro elemento de mayor niel de abstraccin: et
rote.

Iigura 27 Abstraccin de rol
5.4.1 Modelado de la realidad con Roles
Para llear a cabo cualquier proceso de analisis es necesario abstraer lo esencial
de las situaciones expuestas en el modelo de requisitos. Para ello, es importante que las
unidades empleadas para la representacin presenten lmites semanticos bien deinidos
|Deis96|. La clase como elemento de modelado puede presentar ambigedades debido
a que su representacin incorpora no solo los mtodos y atributos imprescindibles para
desempenar su cometido dentro de un caso de uso o escenario concreto, sino el
superconjunto de miembros que se le deduzcan necesarios tras todo el proceso de
analisis. Ln realidad, para deinir el comportamiento de dicha clase en cualquiera de las
istas del sistema basta con deinir el role que juega en el contexto de la ista.
Ll modelo de roles es una abstraccin del modelo de objetos, donde un patrn
de objetos se describe con su correspondiente patrn de roles |Deis96|. As, en lugar
de plasmar un posible escenario dentro del sistema en trminos de conjuntos de clases y
sus interacciones, un modelo de roles tratara de deinirlo en base a los roles que jugaran
las clases que posteriormente los implementen. Una misma clase puede interpretar
dierentes roles dentro del sistema, mientras que un role puede ser interpretado por
clases distintas. Ll modelo de roles muestra como se ha de comportar una de esas clases
en el momento en que est jugando un determinado role.
Rote Cta.e Caigo
Implementa Implementa
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 80
5.4.2 La metodologa OORAM (Object Oriented Role Analysis
and Modelling)
(i) Introduccin
OORAM es una metodologa de analisis y diseno basado en el paradigma de
la orientacin a objetos, pero que introduce el concepto de voaeto ae rote. como
principal mecanismo de abstraccin |Garca98|. Lste mtodo tiene sus orgenes en la
dcada de los anos setenta, y ha sido aplicado por sus creadores en distintos
proyectos de desarrollo.
OORAM ue concebido para el modelado de sistemas grandes. Se
undamenta en los dos siguientes principios:
1. Diriae , revcera.. OORAM plantea la necesidad de diidir los sistemas grandes en
mdulos mas manejables y aciles de comprender. Los subsistemas deducidos
pueden representar actiidades o tareas independientes, de orma que pueda
arontarse su modelado por separado y de orma independiente.
2. ^ivgvv ob;eto e. vva i.ta |Beck89|, lema que subraya el hecho de que el inters de
un objeto iene dado no por su estructura, sino por la orma en la que colabora
con el resto de los objetos del sistema, y que son estas colaboraciones lo que
interesa describir durante el proceso de modelado.
A dierencia de las metodologas orientadas a objetos, OORAM no
contempla los conceptos de clase y herencia durante las actiidades de analisis y
diseno. Las clases son consideradas inadecuadas para la descripcin de actiidades,
dado que una clase describe un conjunto de objetos con propiedades comunes,
mientras que en una actiidad interienen objetos pertenecientes a dierentes clases.
Ll responsable del modelado se muee por tanto en un terreno mas abstracto, siendo
los modelos de roles el concepto en torno al cual se articula todo el proceso de
modelado del sistema |Garca98|.
La primera aclaracin necesaria que se debe realizar es relatia a la primera
airmacin de este apartado: OOR.M e. vva vetoaotoga.`. Ll mtodo OORAM se
deine por su autor no como una metodologa en s, sino como un varco referevciat
para una amilia de metodologas orientadas a objetos. La idea subyacente sobre la
que se ha deinido OORAM es que no hay ninguna metodologa nica e ideal que
solucione cualquier tipo de problema. Se necesitan distintas metodologas para
propsitos dierentes, cada una supeditada a la combinacin de circunstancias de
productos, gente y entorno de inormacin especicos |Reenskaug96|. La
metodologa OORAM es genrica. Desarrolla un marco de trabajo para la creacin
de distintas metodologas. Ademas, aporta su propio lenguaje de modelado, aunque
ya han aparecido diersos estudios que deienden la compatibilidad de OORAM con
el empleo de UML |Garca02|.
OORAM modela los enmenos de inters como estructuras de objetos
interactuantes. Ll voaeto ae rote. es una potente abstraccin que procura una muy
genrica separacin de areas de inters. La .vte.i. del modelo de roles permite la
construccin de modelos complejos a partir de otros mas simples, acilitando a la ez
la aplicacin sistematica de componentes reutilizables.
J) Ll lenguaje de modelado de OORAM.
OORAM aporta su propio lenguaje de modelado, cuyos modelos -aqu
denominados ri.ta.- no encajan exactamente con la clasiicacin deinida en el
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 81
captulo reerente a los lenguajes de modelado. No obstante, son muy cercanas a las
manejadas por los lenguajes de modelado orientados a objetos, como el UML o el
deinido por Booch |Booch93| para el OOAD. Los modelos contemplados por
OORAM son:
1. .rea ae ivtere.. Ls una descripcin textual de la actiidad a modelar.
2. .tvvtore.ve.ta. Muestra los roles del entorno que pueden tanto iniciar la
actiidad en el sistema eniando un mensaje estmulo, como recibir el resultado
producido como respuesta de la actiidad.
3. Cotaboraciv. Representa los roles de un modelo junto con las conexiones que
deinen al interactuar. Los roles se representan mediante elipses, y las
conexiones mediante lneas que pueden o no terminar en un verto. Un puerto
senala la capacidad del rol asociado para el eno de mensajes a tras de la
conexin, es decir, el .evtiao de la conexin.
4. vterfa. Deinicin de la relacin de mensajes susceptibles de ser eniados por
cada puerto. Ls complementario a la ista de colaboracin.
5. .cevario. Ls similar al diagrama de secuencia deinido por UML, con la
saledad de que en este caso lo que se representa no son mensajes entre
instancias de clases, sino mensajes entre ;vgaaore. de roles.
6. Proce.o. Describe los lujos de datos entre los roles y las acciones tomadas por
los roles para procesar los datos |Garca98|.
. evavtica. Vista similar a la de colaboracin, donde las conexiones entre roles
implican relaciones de asociacin. Describe los posibles estados de un rol, y los
mensajes o eentos que disparan las transiciones de estado.
2) La arquitectura de tres modelos de OORAM
Partiendo de la concepcin de OORAM como marco de trabajo para el
desarrollo de metodologas, es necesario establecer una organizacin concreta y
deinir un proceso para cada tipo de problema que sea necesario resoler mediante
un desarrollo sotware. As, realmente debera deinirse una metodologa especica y
especializada, abandonando la idea que deienden otras lneas de inestigacin basada
en el empleo de una metodologa nica para todos los ambitos de desarrollo. Ln esta
lnea, los creadores de OORAM proponen lo que denominan arqvitectvra ae tre.
voaeto. para el modelado de sistema de inormacin de gestin. Se trata de una
metodologa que complementa las premisas dictadas por OORAM y que deine
algunos de los aspectos no contemplados y que deben serlo en cualquier metodologa
de desarrollo.
Los tres modelos a los que hace reerencia el nombre de la metodologa son:
1. Ll voaeto ae evre.a, en el que se identiican los distintos roles que juegan las
personas que orman el dominio de la empresa, y la orma en la que colaboran
para llear a cabo las tareas dentro de la misma.
2. Ll voaeto ae ivforvaciv, centrado en la inormacin que maneja la empresa, y la
orma en la que sta se encuentra relacionada.
3. Ll voaeto ae 1area,erravievta,erricio, que describe las interaces entre usuarios y
los sericios de inormacin.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 82
(ii) Modelo de proceso
Llegados a este punto, es necesario reincidir sobre la airmacin de 1ryge
Reenskaug en la que senala que OORAM no es una metodologa de desarrollo, sino
un marco reerencial |Reenskaug96|. Ln consecuencia, no se describe en su libro
ningn modelo de proceso, sino mas bien la orma adecuada de arontar las tareas de
analisis, disena su transormacin en implementacin, ni siquiera durante la
deinicin de la arquitectura de tres modelos.
Ll modelo de proceso al que induce es mayormente el clasico en cascada, en
el que las distintas actiidades a arontar durante el proceso de desarrollo se suceden
con una clara relacin de dependencia entre ellas, es decir, es necesario terminar una
para poder comenzar la siguiente. No obstante, la idea que deiende OORAM es
precisamente su condicin de marco de trabajo genrico, de orma que no presenta
ninguna incompatibilidad con otros modelos de proceso que, en muchos casos,
consisten en repetir el modelo en cascada pero para subconjuntos de los requisitos
del sistema.
(iii) Actividades del ciclo de desarrollo
J) Anlisis
Ll primer paso de la actiidad de analisis en OORAM es la identiicacin de
las areas de inters del problema a resoler. Una ez deinidas, para cada una de ellas
se ha de crear cada uno de los tres modelos deinidos por la arqvitectvra ae tre. voaeto.
que propone la metodologa.
a) Divisin en reas de interes (Casos de uso).
Se trata de diidir el sistema en un conjunto de actiidades, identiicado
area. of covcerv ,areas de inters,, sobre las que se aplica el modelado de roles
|Deis96|. La separacin en areas de inters esta conceptualmente prxima a la
identiicacin de los casos de uso propuesta en las metodologas basadas en la
orientacin a objetos. De esta orma se obtienen modelos de tamano manejable,
pero se da la circunstancia adersa de que para sistemas grandes, se produce una
descripcin demasiado ragmentada y limitada. Lste inconeniente es atajado
mediante el modelo de .vte.i. ae voaeto..
La sntesis de modelos denota la construccin, en orma segura y
controlada, de un modelo de roles aeriraao a partir de uno o mas modelos de roles
base. La sntesis puede asimilarse a una concepcin genrica de la herencia en la que
sta mantiene una caracterstica esencial de integridad respecto de un modelo de
roles.
Ln la siguiente igura se muestra un ejemplo de modelo de roles que deine
un area de inters posible dentro de cualquier empresa que trabaje con proyectos.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 83

Iigura 28 Ljemplo OORAM
Ll modelo de roles de la igura trata de representar la actiidad de covra
que se suele dar en cualquier proyecto, sea cual sea su naturaleza, cuando alguno de
los miembros detecta una necesidad material. Ll modelo representa la ri.ta ae
cotaboraciv. Los crculos presentes en los extremos de las relaciones representan
verto.. Un puerto en el extremo de una lnea de interaccin determina que el role
asociado en ese extremo puede emitir un mensaje al otro. Ln el ejemplo, Ll
encargado de compras puede comunicarse con el miembro del equipo, pero no as
a la inersa.
b) Creacin del modelo de empresa.
Para cada area de inters, se deine el modelo de empresa. Para ello se
emplean:
1. Moaeto o ri.ta ae cotaboraciv
2. Moaeto. ae e.cevario.
3. Moaeto o ri.ta ae roce.o. Muy til para identiicar las inormaciones y tareas
implicadas.
c) Creacin del modelo de informacin
Ln este modelo se debe crear la ista semantica de los roles que representan
la inormacin extrada del modelo de empresa, con reerencia a los datos
identiicados durante la elaboracin de la ista de proceso.
Ll modelo de inormacin puede ser nico para todas las areas de inters
identiicadas, en lugar de ragmentado en trozos, uno para cada una de ellas.
d) Creacin del modelo 1area/Herramienta/Servicio
Se crea una ista de proceso para cada tarea realizadas por alguno de los
usuarios. La ista de proceso, en este caso, siempre sigue el esquema
1. rol v.vario.
2. rot berravievta evteaaa.
3. cov;vvto ae rote. ae .erricio. ae ivforvaciv.
2) Diseo
La actiidad de diseno en OORAM no se encuentra estrictamente deinida,
sino que su especiicacin queda mas bien abierta a las distintas metodologas
especicas que se creen dentro del marco de trabajo. Ln el caso de la arquitectura de
Miembro
Jefe de
Proyecto
Encargado
Compras
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 84
tres modelos, el modelo de diseno, al estilo de lo que deienden las metodologas
orientadas a objetos en general, se presenta como un reinamiento del modelo
obtenido durante el analisis.
a) Obtencin del modelo de base de datos e identificacin de clases a partir del
modelo de informacin.
La proximidad conceptual del modelo de inormacin a los modelos de
entidad relacin empelados para el diseno de bases de datos relacionales hacen que
esta actiidad resulte practicamente directa, particularmente, a partir de su ista
semantica. As mismo, es relatiamente sencillo transormarlo en un diagrama de
clases, tal y como se entiende ste en los lenguajes de modelado orientados a
objetos, como el UML.
Las clases deducidas del modelo de inormacin se denominan cta.e. aet
avati.i. o cta.e. aet voaeto. Lncapsulan el acceso a base de datos, y su presencia
propicia la separacin de responsabilidades.
b) Identificacin de las reglas de negocio a partir del modelo de empresa.
Lstas reglas deberan implementarse mediante cdigo uente en las clases
identiicadas a partir del modelo de inormacin, o bien en nueas clases si as se
considera necesario.
c) Definicin de interfaces grficas a partir del modelo de
1area/Herramienta/Servicio
Lste modelo es especialmente til a la hora de disenar las herramientas
mediante las cuales el usuario inal del sistema interactuara con el mismo una ez
ste sea implantado en produccin.
(iv) Consideraciones
Ll modelo de roles propuesto por OORAM aporta una gran ersatilidad a la
hora de realizar documentos de analisis, puesto que permite representar las
interacciones entre los integrantes de una relacin, sin necesidad de llegar a
especiicar a que tipo concreto pertenecen dichos integrantes. De esta orma se
soluciona uno de los problemas que se dan habitualmente a la hora de modelar
sistemas orientados a objetos, puesto que el analista se puede er orzado a
determinar anticipadamente tipos o clases de objetos, pudiendo incurrir en errores
que deberan ser corregidos con posterioridad.
Ln aspectos mas tcnicos, entrando en el diseno, los modelos de roles
pueden ser empleados para la deinicin de patrones de diseno. Cuando se deine un
patrn, no se especiican las clases concretas que an a implementarlo dentro del
contexto del caso de uso en realizacin, puesto que puede hacerse de orma
independiente. Por el contrario, lo que realmente se hace es determinar el
comportamiento de los roles que dichas clases jugaran dentro del patrn.
Ln tercer lugar, es debido destacar la compatibilidad que, gracias a su
lexibilidad, presenta OORAM con UML, el lenguaje de modelado estandarizado por
el OMG |OMG|. La adaptacin del voaeto ae arqvitectvra ae tre. caa. propuesto por
Reenskaug ha sido tratada por diersos autores, habindose obtenido resultados
positios en todos los casos |Garca02|. Lsto, dada la extensia adopcin del UML
como lenguaje de modelado por las metodologas actuales ,especialmente RUP,, abre
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 85
un amplio abanico de posibilidades de integracin entre OORAM y las metodologas
que carezcan del modelo de roles o equialente.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 86
5.5 METODOLOGAS GILES DE DESARROLLO
Partiendo de la experiencia acumulada durante muchos anos de trabajo en el sector
del desarrollo del sotware, un determinado conjunto de desarrolladores llegaron a la
conclusin de que los mtodos de desarrollo de sotware existentes hasta el momento no se
adecuaban bien a los proyectos reales que se presentan en el mercado actual. 1odas las
metodologas, como se coment anteriormente, parten del principio de aplicar los mtodos
de ingeniera clasica a la tarea de desarrollar sotware. Las caractersticas principales de estas
metodologas clasicas o pesadas son su caracter eminentemente predictio -dado que todas
se centran en una planiicacin que se desarrolla en momentos tempranos de la ida del
proyecto- y una carga mas o menos importante de labores burocraticas. La crtica mas
diundida y aceptada a este tipo de metodologas se resume en que a, tavto qve bacer ara
.egvir ta vetoaotoga qve et ritvo evtero aet ae.arrotto .e retaraa.`|lowler03|.
Como reaccin a estas metodologas, un nueo grupo de metodologas ha surgido
en los ltimos anos. Durante algn tiempo se conocan como las metodologas ligeras, pero
el trmino aceptado ahora es metodologas agiles. Para mucha gente el encanto de estas
metodologas agiles es su reaccin a la burocracia de las metodologas clasicas. Lstos
nueos mtodos buscan un punto medio de equilibrio entre ningn proceso y demasiado
proceso, proporcionando simplemente suiciente proceso para que el esuerzo alga la
pena.
Ll resultado de todo esto es que las metodologas agiles rompen con alguno de los
axiomas sobre los que se undamentan las metodologas basadas en el mundo de la
ingeniera clasica. La dierencia inmediata es que son menos orientadas al documento,
exigiendo una cantidad mas pequena de documentacin para una tarea dada. Ln muchos
aspectos son mas bien orientadas al cdigo, basandose en la creencia de que la parte mas
importante de la documentacin es el cdigo uente.
Las dierencias esenciales entre las metodologas agiles y las clasicas se pueden
resumir en que:
1. Los mtodos agiles son adaptables en lugar de predictios. Los mtodos ingenieriles
tienden a intentar planear una parte grande del proceso del sotware en gran detalle
para un plazo grande de tiempo. Lsto unciona bien hasta que las cosas cambian y,
debido a ello, cuentan con mecanismos -poco eectios- para resistirse al cambio
6
.
Para los mtodos agiles, no obstante, el cambio es bienenido. Intentan ser procesos
que se adaptan y crecen en el cambio, incluso al punto de cambiarse ellos mismos.
2. Los mtodos agiles son orientados a la gente y no orientados al proceso. La meta de
los mtodos ingenieriles es deinir un proceso que uncionara bien con cualquiera
que lo use. Los mtodos agiles airman que ningn proceso podra nunca maquillar
las habilidades del equipo de desarrollo, de modo que el papel del proceso es apoyar
al equipo de desarrollo en su trabajo. Lxplcitamente puntualizan el trabajar a aor
de la naturaleza humana en lugar de en su contra y enatizan que el desarrollo de
sotware debe ser una actiidad agradable.

6
Ln la mayora de las metodologas clasicas, el documento resultante del analisis de requisitos es en esencia el
contrato entre el cliente y el desarrollador, de orma que ni el cliente puede exigir nada que no conste en
dicho documento, ni el desarrollador puede dejar de cumplir ninguno de estos requisitos.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 87
Las metodologas mas caractersticas de esta amilia son XP, SCRUM y Cristal.
1odas ellas comparten los principios que las deinen como metodologas agiles, pero la mas
pupilar es sin duda XP ,e`treve Progravvivg,, cuyo ormato es el de un conjunto de
recomendaciones y tcnicas que no son mas que mtodos para las distintas actiidades del
ciclo de ida de un proyecto.
5.5.1 eXtreme Progamming
(i) Introduccin
treve rogravvivg, tambin conocida como `P, es una de las metodologas
agiles anteriormente comentadas que surgen con animo de relegar a las metodologas
clasicas habitualmente inspiradas en la ingeniera industrial. Las races del XP se
encuentran en la comunidad de desarrolladores de vatt1at/. Los creadores de XP,
Kent Beck y \ard Cunningham comenzaron a colaborar a comienzos de los anos
80. Como ruto de esa colaboracin a lo largo de los anos, ambos ueron poco a
poco identiicando puntos negros en las metodologas de desarrollo, y suplindolos
por tcnicas concretas que solucionaba determinados problemas de dichas
metodologas mediante la aplicacin de nueos enoques. La coleccin de todos esos
mtodos es lo que se denomina XP, y que hoy conocemos como la mas diundida
metodologa agil.
(ii) Modelo de proceso
1odas las metodologas agiles comparten el mismo modelo de proceso
eminentemente iteratio. Centran el desarrollo del proyecto en ciclos relatiamente
cortos, dependiendo de la metodologa. XP en concreto sugiere ciclos de entre una y
tres semanas, y SCRUM iteraciones de un mes.

Iigura 29 Modelo de proceso XP
Ll basarse en el modelo iteratio supone un mecanismo de deensa ante la
asuncin sobre la que se construyen estas metodologas: los cambios en los requisitos
del cliente. Dado que el mayor problema de las metodologas clasicas es
precisamente su ulnerabilidad ante el cambio, las metodologas agiles optan por
trabajar con ciclos muy cortos cuyos resultados alimenten a los ciclos posteriores. La
clae es pues producir recuentemente ersiones que uncionen del sistema inal que
tengan un subconjunto de los requisitos solicitados, de uncionalidad limitada pero
Anlisis
Diseo
Implementacin
Pruebas
En cascada Iterativo XP
Alcance
Tiempo
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 88
ieles a las demandas del sistema inal. De esta orma, los cambios son asimilados por
el equipo de desarrollo en ases tempranas del desarrollo, y caso de tener que
despreciar cdigo ya producido debido a ello, al menos se asegura la independencia
del resto del sistema de ste cdigo, dado que an no ha sido construido.

Iigura 30 Coste del cambio en metodologias clsicas
Ln el graico anterior se aprecia que el impacto que supone un cambio en los
requisitos iniciales del sistema si se aplica una metodologa clasica es mayor cuanto
mas tarde se produzca ese cambio. Ln la siguiente igura, se muestra el impacto que
tericamente supone en una metodologa agil. Al trabajar con ciclos muy cortos, los
requisitos errneos y las posibles mejoras saltan a la ista del cliente antes de que su
modiicacin suponga un problema graa para el equipo de desarrollo. Supongamos
que una constructora de iiendas esta construyendo un ediicio de seis plantas para
un propietario que no aprecia exactamente la realidad utura cuando se la ensenan en
un plano. Si el cliente isita la obra cada ez que se construya un piso, puede solicitar
que tal tabique sea desplazado unos metros aqu o alla, sin que esto suponga un
desastre en el proceso de construccin del ediicio. Sin embargo, si slo aprecia los
resultados en el momento de la entrega, su descontento no tendra solucin.

Iigura 3J Coste del cambio en metodologias giles
(iii) Las prcticas propuestas por XP
XP no responde al ormato habitual que suelen presentar las metodologas,
sino que se presenta como un conjunto de recomendaciones o pautas de desarrollo
de distinta naturaleza. As, algunas de ellas, como la planiicacin, responden a
actiidades de administracin del proyecto, y otras como el Pair Progravvivg son
mtodos que tratan de mejorar la actiidad de implementacin del proyecto. A
continuacin, enumeramos las practicas de XP, por considerar esta como la mas
REQUISITOS ANLISIS DISEO IMPLEMENTACIN PRUEBAS PRODUCCIN
C
O
S
T
E

D
E
L

C
A
M
B
I
O

REQUISITOS ANLISIS DISEO IMPLEMENTACIN PRUEBAS PRODUCCIN
C
O
S
T
E

D
E
L

C
A
N
B
!
O

Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 89
representatia y exitosa de las metodologas agiles aparecidas hasta el momento
|Acebal02|:
J) La planificacin
XP plantea la planiicacin como un permanente dialogo entre la parte
empresarial y tcnica del proyecto, en la que los primeros decidiran el alcance, la
prioridad, la composicin de las ersiones y la echa de las mismas. Los tcnicos son
los responsables de estimar la duracin requerida para implementar las
uncionalidades deseadas por el cliente, de inormar sobre las consecuencias de
determinadas decisiones, de organizar la cultura de trabajo y, inalmente, de realizar
la planiicacin detallada dentro de cada ersin.
Se trata de determinar rapidamente el alcance de la ersin siguiente,
combinando prioridades de negocio deinidas por el cliente con las estimaciones
tcnicas de los programadores. Lstos estiman el esuerzo necesario para implementar
las historias del cliente y ste decide sobre el alcance y la agenda de las entregas. Las
historias se escriben en pequenas ichas, que algunas eces se tiran, de orma que en
ocasiones lo nico restante que se parece a un requisito es una multitud de pruebas
automatizadas, las pruebas de aceptacin.
2) Versiones pequeas
Ll sistema se pone por primera ez en produccin en, a lo sumo, dos o tres
meses, antes de estar completamente terminado. Las sucesias ersiones seran mas
recuentes, entre un da y un mes. Ll cliente y el equipo de desarrollo se beneiciaran
de la retroalimentacin que produce un sistema uncionando, y esto se relejara en
sucesias ersiones.
3) Metfora
Un sistema de nombres comn y una descripcin comn
4) Diseo simple
Ln ez de perseguir a toda costa un diseno en el que hemos de desarrollar
dotes adiinatorias para tratar de anticiparnos al uturo, lo que XP deiende es
disenar en cada momento para las necesidades presentes.
S) 1esting
Cualquier caracterstica de un programa para la que no haya un test
automatizado, simplemente no existe. Lste es sin duda el pilar basico sobre el que se
sustenta XP. Otros principios son susceptibles de ser adaptados a las caractersticas
del proyecto, de la organizacin, del equipo de desarrollo... Pero aqu no hay
discusin posible: .i vo bacevo. te.t., vo e.tarevo. bacievao `P` |Acebal02|. Para ello, se
debe emplear algn ramework de testing automatico, como JUnit |JUnit| o
cualquiera de sus ersiones para dierentes lenguajes.
Los test deberan ser escritos antes incluso que la propia clase a probar. Lsto
ayuda al principio de programacin por intencin, esto es, a escribir el cdigo como
si los mtodos mas costosos ya hubieran sido escritos, y slo tuiramos as que
eniar el correspondiente mensaje, de manera que el cdigo releje bien su intencin
y se documente a s mismo. Ln el sitio web de JUnit mencionado en el parrao
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 90
anterior se pueden encontrar interesantes artculos que explican cmo deben
escribirse estos tests.
6) Refactoring
Responde al principio de simplicidad. \, muy escuetamente, consiste en dejar
el cdigo existente en el estado mas simple posible, de manera que no pierda ni gane
uncionalidad, y que se sigan ejecutando correctamente todos los tests. Lsto pretende
hacer sentir al desarrollador mas cmodo con el cdigo ya escrito y, por tanto,
menos reacio a modiicarlo cuando haya que anadir o cambiar alguna caracterstica.
Ln el caso de sistemas heredados, o de proyectos que se tomen ya empezados,
seguramente habra que dedicar arias semanas slo a actorizar el cdigo.
Ln el caso de mantenimiento eolutio de sistemas heredados, XP
recomienda la reactorizacin completa del cdigo alla donde sea necesario. La
practica tambin se conoce como Me;ora Covtivva ae Caigo o Refactoriaciv ivtacabte.
7) Pair programming
1odo el cdigo sera desarrollado en parejas compartiendo un solo monitor y
teclado. Quien codiica estara pensando en el mejor modo de implementar un
determinado mtodo, mientras que su companero lo hara de una manera mas
estratgica ,Lstamos siguiendo el enoque apropiado ,Qu es lo que podra allar
aqu ,Qu deberamos comprobar en los tests ,lay alguna manera de simpliicar el
sistema
Por supuesto, los roles son intercambiables, de manera que en cualquier
momento quien obseraba puede tomar el teclado para ejempliicar alguna idea o,
simplemente, para turnar a su companero. Igualmente, la composicin de las parejas
cambiara siempre que uno de los dos sea requerido por algn otro miembro del
equipo para que le ayude con su cdigo.
8) Propiedad colectiva del cdigo
Cualquiera puede modiicar cualquier porcin del cdigo, en cualquier
momento, siempre que escriba antes el conjunto de pruebas correspondiente.
Cualquiera que ea una posibilidad de simpliicar, mediante refactorivg, cualquier clase
o cualquier mtodo, hayan sido o no escritos por l, debera hacerlo sin mas dilacin.
Ll uso de estandares de codiicacin y la conianza que nos dan los tests de que todo
a a seguir uncionando bien tras una modiicacin, hacen que esto no sea ningn
problema en XP.
9) Integracin continua
Cada pocas horas o al cabo de un da de programacin, como mucho, se
integra el sistema completo Para ello existira un maquina as llamada, de integracin,
a la que se acercara una pareja de programadores cada ez que tengan una clase que
haya sido probada unitariamente. Si al anadir la nuea clase junto con sus tests
unitarios, el sistema completo sigue uncionando correctamente, los programadores
daran por inalizada esa tarea. Si no, seran los responsables de dejar el sistema de
nueo con los tests uncionando al 100. Si despus de un cierto tiempo no son
capaces de descubrir qu es lo que alla, tiraran el cdigo a la basura y oleran a
comenzar de nueo.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 91
J0) 40 horas semanales
XP parte de que si realmente se quiere orecer calidad, y no meramente un
sistema que uncione en necesario que cada miembro del equipo se leante cada
manana descansado y se aya a las 6 de la tarde a su casa cansado y con la
satisaccin del trabajo bien hecho, y que al llegar el iernes sepa que cuenta con dos
das para descansar y dedicarse a cosas que nada tengan que er con el trabajo.
Naturalmente, las 40 horas no es una regla ija -puede ir de 35 a 45-, pero lo que es
seguro es que nadie es capaz de trabajar 60 horas a la semana y hacerlo con calidad.
JJ) Cliente en el sitio
XP airma que al menos un cliente real debe estar permanentemente junto al
equipo de desarrollo, para responder cualquier consulta que los programadores le
planteen, para establecer prioridades, etc.
J2) Lstndares de codificacin
Se deben seguir reglas de codiicacin y comunicarse a tras del cdigo. Ls
crucial que los integrantes del equipo se pongan de acuerdo en estilos de notacin,
indentacin y nomenclatura, as como en un alor apreciado en la practica, el llamado
cdigo reelador de intenciones`. Como en XP rige un cierto purismo de
codiicacin, los comentarios no son bien istos. Si el cdigo es tan oscuro que
necesita comentario, se debe reescribir o reactorizar.
(iv) Consideraciones
Como es predecible tras la lectura de los rasgos principales del XP, se trata de
una metodologa que a pocos proesionales ha dejado indierentes. Ante su aparicin
se ha creado una controersia y un autntico debate que recuerda al suscitado en los
anos 60 cuando se reconoci la existencia de la amosa cri.i. aet .oftrare.
Por un lado, sus detractores esgrimen no sin cierta razn argumentos que, en
parte, son tambin reconocidos por sus propios creadores. As, el propio Beck
reconoce que se trata de una metodologa apropiada cuando el tamano del proyecto
es medio o pequeno, y que las experiencias positias sobre las que se ampara a la
hora de deenderlo han sido siempre con equipos de gente cualiicada. Una de las
premisas mas diciles de cumplir es sin duda la presencia continuada del cliente en el
equipo de desarrollo, algo que ninguna metodologa desestimara pero que, a la hora
de la erdad, no suele ser actible. Lllo implica un inters y esuerzo por parte del
cliente que muchas eces no se dara en proyectos reales.
XP desprecia la documentacin en demasa. Ll salto de abstraccin entre los
requisitos y el cdigo como nica uente de documentacin es demasiado grande
como ara que en una supuesta utura incorporacin de un miembro nueo al equipo,
comprenda el sistema a partir de cierto tamano.
Por otro lado, por primera ez se asume un hecho actico en todo proyecto
sotware: el siempre presente cambio en los requisitos del proyecto. 1cnicas como
la integracin continua, las pruebas unitarias o el empleo de estandares de
codiicacin son perectamente compatibles en la mayora de las metodologas y,
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 92
ademas, importantes puntos a aor que consiguen eitar problemas habitualmente
tardos

que desembocan en retrasos en la planiicacin inicial del proyecto.


5.6 METODOLOGAS DE DOMINIO ESPECFICO
1al y como resulta eidente tras la lectura de los apartados anteriores del presente
captulo, en l no se han descrito todas las metodologas existentes, ni mucho menos. Ll
alcance del estudio se ha limitado slo a las mas importantes y representatias de cada
amilia, incidiendo sobre aquellas que, por proximidad conceptual con la POC, pueden
resultar mas tiles como punto de partida para la adaptacin a los requisitos del modelado
de conjuntos. Algunas han sido excluidas conscientemente por considerarse que no deben
ser clasiicadas dentro de una naturaleza que responde nicamente al paradigma
tecnolgico del proyecto, sino que deben ser organizadas en base a otros parametros. Ls el
caso de las metodologas de dominio especico, a comentar en el presente apartado, y de
las metodologas hbridas.
Denominamos metodologa de dominio especico a aquellas que han sido
disenadas para construir soluciones sotware que responden a periles muy concretos cuya
caracterstica dierenciadora no es la naturaleza tecnolgica de los proyectos que estan
orientadas a gestionar. Ln muchos casos, su ambito se encuentra localizado en un
subconjunto de las amilias ya descritas.
Ln este caso se encuentran, por ejemplo, las metodologas orientadas al desarrollo
de aplicaciones hipermedia. Lxisten arias metodologas para desarrollo de este tipo de
productos, y no todas ellas estan orientadas al desarrollo del mismo tipo de aplicaciones.
Ln principio existen dos grandes grupos: las que estan basadas en un modelo de datos
relacional como lDM ,lypermedia Design Model,, RMM ,Relationship Management
Metodology, y RMM extendido, y otras basadas en un modelo de datos orientado a objetos
como OOlDM ,Object Oriented lypermedia Design Metodology, LORM ,Lnhanced
Object Relationship Model, y la metodologa desarrollada en el departamento de
inormatica de la UC3M.
Ln el mismo caso podramos clasiicar las metodologas orientadas al desarrollo de
sistemas basados en conocimiento, como KADS o su extensin CommonKADS |Labrana|
|Daid93| |Cadas96|. Lste tipo de metodologas se centran en el diseno de la base de
conocimiento y en la orma de organizar y recopilar la inormacin y las reglas que
determinan su comportamiento.
As mismo, englobaramos dentro de esta amilia todas aquellas orientadas al
desarrollo de sotware para equipos hardware muy especicos o soluciones particulares,
caso bastante habitual dentro de la industria para el desarrollo de sotware de autmatas,
PLCs, etc.
Como ltimo apunte, es obligado senalar que, dentro de este apartado, se deben
destacar los proyectos de desarrollo de compiladores e intrpretes |Aho85| |lolub90|. La
metodologa de desarrollo de este tipo de herramientas es, sin duda, una de las mas
cercanas a las aplicadas en el mundo de la industria clasica, tanto por su ormato como por
su eectiidad. Las peculiares caractersticas que implican la deinicin lxica, sintactica y

Los errores de integracin proocados por una inadecuada descripcin de interaces no son detectados en
los proyectos guiados por metodologas clasicas hasta la ase de pruebas de integracin, y su aparicin
prooca el retroceso del proyecto de nueo a la ase de construccin.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 93
semantica de un procesador de lenguaje dejan muy poco margen para la desiacin del
proceso de desarrollo, acilitando as la normalizacin de las actiidades implicadas en este
tipo de proyectos. Ln consecuencia, se trata de un tipo de metodologa muy estricta y con
una base ormal muy uerte, pero que es de escasa aplicacin al desarrollo de sotware de
gestin en general.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 94
5.7 METODOLOGAS HIBRIDAS
Sin llegar a encajar como metodologas de ambito especico, hay otro conjunto de
metodologas an no citadas que merecen un apartado singular dentro de la presente
clasiicacin. Se trata de las que denominaremos bbriaa., por contemplar dentro de sus
objetios proyectos que pueden responder a distintas naturalezas tecnolgicas.
Ll origen de este tipo de metodologas suele encontrarse en el inters de algunas
organizaciones por satisacer objetios distintos de los puramente tcnicos. Debido a ello,
no se ocalizan sobre un determinado paradigma o tecnologa de desarrollo, sino en otros
aspectos independientes de la plataorma y mas relacionados con la gestin de los
proyectos.
5.7.1 La metodologa MTRICA 3
(i) Introduccin
ML1RICA ue creada en 1989 por encargo del gobierno espanol, con el
objeto de normalizar los proyectos de desarrollo que se dieran en la administracin
pblica espanola, tal y como hizo lrancia con la metodologa para el desarrollo de
sistemas de inormacin Meri.e.
Ln sus anteriores ersiones ,2.1 de 1995, desarrollada por la Uniersidad
Carlos III, Mtrica empleaba nicamente la notacin de DeMarco para la generacin
de diagramas y modelos que permitieran representar el dominio, el analisis y el
diseno del proyecto. Debido al auge de las tecnologas orientadas a objetos, y a la
imposibilidad de representar modelos OO mediante la notacin basada en DlDs, en
la ersin actual de Mtrica se ha incorporado UML como lenguaje de modelado
alternatio. As, Mtrica 3 permite desarrollar tanto proyectos basados en el analisis
estructurado de DeMarco, como proyectos que sigan el paradigma de la orientacin a
objetos.
(ii) Modelo de proceso
Las primeras ersiones de ML1RICA, como se senalo anteriormente,
responden al peril de las metodologas clasicas orientadas al lujo de inormacin.
As, la caracterstica del modelo de proceso en cascada ha sido heredada de ersin
en ersin hasta la actual.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 95

Iigura 32 Procesos y actividades cubiertas por ML1RICA 3
(iii) Actividades del ciclo de desarrollo
Ll tratamiento de estas actiidades dentro de ML1RICA es completamente
heredado de los propuestos por DeMarco y RUP. La solucin de mtrica ante la
dicotoma tecnolgica de los proyectos que pretende abarcar se limita a especiicar
cuales de las actiidades
8
que describe la metodologa se deben aplicar en uno o en
otro caso. Lsto se puede apreciar, por ejemplo, en la siguiente igura que esquematiza
las actiidades del proceso de diseno descrito por ML1RICA:

8
Ln este contexto, el trmino actiriaaa manejado por ML1RICA se corresponde con el de vetoao empleado
hasta ahora.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 96

Iigura 33 Proceso DSI ML1RICA 3
5.7.2 Actividades de administracin y gestin del proceso de
desarrollo
ML1RICA se caracteriza por estar muy orientada a la gestin y coordinacin
de los proyectos de desarrollo. Las especiicaciones de los proyectos descritos por
ML1RICA llegan a especiicar incluso el contenido y estructura de los arteactos o
documentos que deben ser generados tras la ejecucin de cada una de las tareas, los
periles participantes en las mismas y las responsabilidades de cada uno de ellos.
Como nota puntual, ML1RICA describe incluso mtodos para abordar las
actiidades propias de la ase de mantenimiento del producto, algo poco habitual en
las metodologas de desarrollo.
Otra de las actiidades cubiertas excepcionalmente por ML1RICA es el PSI
o Plan de Sistemas de Inormacin, actiidad orientada al estudio de la organizacin
desde un punto de ista global, tras la cual pueden surgir las especiicaciones y
propuestas de distintos proyectos de desarrollo.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 97
CAPTULO VI HERRAMIENTAS CASE
6.1 INTRODUCCIN
C. e. ta avtovatiaciv aet .oftrare` |Macclure85|.
La ingeniera de sistemas asistida por ordenador ,Covvter.iaea ,.tev. vgiveerivg -
CASL, es la aplicacin de tecnologa inormatica a las actiidades, las tcnicas y las
metodologas propias de desarrollo de sistemas, y al igual que las herramientas CAD o
CAM, su objetio es acelerar el proceso para el que han sido disenadas |Kendall91|.
Concretamente, una herramienta CASL es un producto computacional enocado a apoyar
una o mas tcnicas dentro de un mtodo de desarrollo de sotware |Jarzabek98|. La
automatizacin de los distintos procesos de desarrollo presentes durante la elaboracin de
un producto sotware suele ser la clae para conseguir cumplir las planiicaciones iniciales
del proyecto.
6.1.1 Orgenes
Ln la dcada de los setenta el proyecto ISDOS desarrollo un lenguaje llamado
Probtev tatevevt avgvage` ,PSL,, orientado a la descripcin de los problemas de
usuarios y las necesidades de solucin de un sistema de inormacin en un diccionario
computerizado. Ll Probtev tatevevt .vat,er ,PSA, era un producto asociado que
analizaba la relacin de problemas y necesidades.
Ln la lnea de las ideas promulgadas por el PSL, surge la que sera la primera
herramienta CASL, tal y como hoy la conocemos. ceterator apareci en 1984 para la
plataorma PC. Partiendo de este producto se ha desarrollado una importante amilia de
productos que, a medida que la tecnologa eolucionaba, se ha ido diersiicando hasta
cubrir todos los aspectos organizatios y tecnolgicos de los proyectos sotware. Ln el
caso concreto de la orientacin a objetos, son resenables las herramientas desarrolladas
por Rational ,Ratiovat Ro.e, y por Borland ,1ogetber Covtrot Cevter,.
6.2 TECNOLOGA CASE
La tecnologa CASL supone la automatizacin del desarrollo del sotware,
contribuyendo a mejorar la calidad y la productiidad en el desarrollo de sistemas de
inormacin. Para mejorar la calidad y la productiidad de dichos sistemas a la hora de
construir sotware se plantean los siguientes objetios:
a. Pervitir ta aticaciv ractica ae ta. vetoaotoga. re.ataaaa. or ta berravievta. La relacin
entre metodologa y herramienta CASL es complementaria y simbitica. Ninguna
metodologa sera implantada y ,o aplicada con xito en un proyecto de desarrollo
de sotware si no cuenta con herramientas que permitan automatizar y aplicar su
uso. Por otro lado, ninguna herramienta CASL tiene sentido si no se encuentra
orientada a la aplicacin practica de una metodologa de desarrollo. Por lo tanto,
este es uno -si no el mas- de los objetios mas importantes de este tipo de
tecnologas.
b. acititar ta reatiaciv ae rototio. , et ae.arrotto cov;vvto ae aticaciove.. Ll hecho de
contar con la inormacin relatia al modelo de desarrollo como inormacin
estructurada manejable por la herramienta CASL abre un sin in de posibilidades en
lo relatio a la generacin de cdigo. loy en da, el paso del diseno detallado al la
implementacin se ha acortado considerablemente, dado que las herramientas
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 98
CASL modernas permiten generar los esqueletos de los elementos que conorman
el producto a realizar, delegando en los desarrolladores las tarea de implementar
dichas piezas.
c. ivtificar et vavtevivievto ae to. rograva.. ntimamente ligado al concepto de
herramienta CASL se encuentra la tcnica denominada ingeniera inersa, mediante
la cual se trata de extraer inormacin estructurada y organizada de productos de
sotware ya desarrollados. Pese a que eidentemente no es posible rehacer el
analisis desde el cdigo, las herramientas que contemplan ingeniera inersa acilitan
considerablemente la habitual tarea de comprender cdigo indocumentado para
abordar un proceso de mantenimiento del producto.
Me;orar , e.tavaariar ta aocvvevtaciv. Al igual que es posible generar parte del cdigo
uente en base al modelo disenado mediante la herramienta CASL, es actible la
generacin de la documentacin descriptia de dicho cdigo.
.vvevtar ta ortabitiaaa ae ta. aticaciove..
acititar ta revtitiaciv ae covovevte. .oftrare.
g. Pervitir vv ae.arrotto , vv refivavievto ri.vat ae ta. aticaciove., veaiavte ta vtitiaciv ae
grafico..
Ln deinitia, el objetio de la tecnologa CASL es aumentar la productiidad de las
actiidades propias del desarrollo y mantenimiento de los sistemas inormaticos, teniendo
siempre como lnea objetio la mejora de la calidad del sotware desarrollado.
6.3 CLASIFICACIN
CASL es una combinacin de herramientas sotware ,aplicaciones, y de
metodologas de desarrollo Las herramientas permiten automatizar el proceso de desarrollo
del sotware, mientras que las metodologas deinen los procesos automatizar. Ln un
primer trmino, debemos dierenciar aquellos productos denominados CASL entre 1oot
Ca.e e Ca.e.
Ll trmino 1oot Ca.e se reiere a aquellas herramientas que permiten automatizar una
actiidad concreta dentro de alguna de las ases del ciclo de ida del sistema
inormatico: Planiicacin estratgica, analisis, diseno, generacin de programas. No se
comunican con otras herramientas CASL.
Los paquetes Ca.e son conjuntos integrados de herramientas que dan soporte a la
automatizacin del proceso completo de desarrollo del sistema inormatico. Permiten
cubrir el ciclo de ida completo. Ll producto inal aportado por ellas es un sistema en
cdigo ejecutable y su documentacin. Ln este grupo se encuentran herramientas
CASL como Ratiovat Ro.e, o el 1ogetber Covtrot Cevter. La entaja principal de estas
herramientas y las disponibilidad de absolutamente toda la inormacin del modelo por
parte de todas las herramientas que cubren cada una de las ases del desarrollo del
proyecto.
Mas habitualmente, este tipo de herramientas son clasiicados en base al ambito que
abarcan dentro del proceso de desarrollo:
1. Case de Alto Niel ,|er Ca.e,
2. Case de Medio Niel ,Miaate Ca.e,
3. Case de Bajo Niel ,orer Ca.e,
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 99
4. lerramientas de Ingeniera Inersa
5. lerramientas de Ingeniera de Ida y Vuelta.
6. lerramientas de ambito especico.
6.3.1 Herramientas Upper Case
Contemplan procesos de planiicacin estratgica captura de requisitos
uncionales de cliente o planes corporatios. Son de muy alto niel y practicamente se
encuentran desligadas de cualquier aspecto tcnico del proyecto, dado que se emplean
en las primeras ases del proyecto.
6.3.2 Herramientas Middle Case
Son herramientas destinadas a las actiidades de analisis y diseno del proyecto.
La rontera entre estas con las |er Case y las orer Ca.e es muy diusa, hasta el punto
que muchos autores omiten esta posibilidad a la hora de establecer una clasiicacin.
lay que tener en cuenta que si bien el analisis se encuentra idneamente aislado de los
detalles de implementacin y despliegue, el diseno esta irmemente ligado a aspectos
tcnicos de bajo niel dentro del proyecto.
6.3.3 Herramientas Lower Case
1ratan los aspectos de bajo niel dentro del proyecto. Normalmente estan
orientadas a la generacin de cdigo, pruebas, implementacin y mantenimiento del
producto. Pese a que las responsabilidades que cubren se encuentran algo menos ligadas
a la ingeniera del sotware que las de mayor niel, juegan un papel muy importante a la
hora de abordar un proyecto, puesto que entre ellas debemos incluir todas aquellas
orientadas a automatizar la generacin de cdigo uente.
6.3.4 Herramientas de ingeniera inversa
Aunque podran englobarse dentro de las herramientas CASL de bajo niel, no
se corresponden exactamente con el concepto anteriormente deinido. Las herramientas
de ingeniera inersa surgen a raz de los problemas con los que habitualmente se
encuentran los desarrolladores a la hora de abordar un proyecto de mantenimiento. La
habitual ausencia de documentacin proocada bien por los plazos de desarrollo
irreales, bien por la carencia de cualiicacin deriada de la inexistente regulacin del
mercado de desarrollo, obliga al desarrollador a interpretar el cdigo uente desarrollado
por otra persona, tarea que en ocasiones puede llegar a ser inabordable.
Como solucin a este tipo de situaciones, surgen las herramientas de ingeniera
inersa. Lstas basan su uncionamiento en la interpretacin del cdigo uente del
producto y generan, en la medida de lo posible, la documentacin de bajo niel
deducible de los icheros uente. Desgraciadamente, pese a que la idea motora es muy
atractia, la aplicacin practica se encuentra muy limitada. Ll lmite alcanzable por esta
tcnica se encuentra en la rontera entre el analisis y el diseno detallado. No es posible
deducir las abstracciones de la inormacin manejadas durante la ase de analisis
partiendo simplemente del cdigo uente del producto, puesto que dichas abstracciones
son precisamente eliminadas durante la actiidad de diseno. As por ejemplo, lo que en
el analisis era una entidad ibro, probablemente derie en un tipo abstracto de dato
denominado 1ibro, o en un bean jaa llamado ibroeav. La complejidad del problema
se acenta cuando no se cont inicialmente con ningn conenio de nombres que
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 100
obligara al desarrollador a emplear literales signiicatios, situaciones en las cuales nos
podemos encontrar casos extremos como ariables denominadas a, q, f1:, etc.
Otro punto dbil de esta tcnica se maniiesta cuando se trata de generar
documentacin que describa aspectos dinamicos del sistema. A la hora de generar
diagramas que relejan el comportamiento del modelo, el analista no plasma la totalidad
de los mensajes susceptibles de ser intercambiados entre todos los elementos que
conorman el sistema. Por el contrario, slo se representaran aquellos que aportan algo a
la comprensin del modelo a desarrollar, puesto que el cometido de dichos diagramas es
precisamente acilitar la comunicacin entre analista o disenador y desarrollador.
Pese a las limitaciones descritas, los resultados orecidos en cuanto a la
descripcin de los aspectos estaticos del sistema suelen ser de gran utilidad. La
obtencin de un diagrama de clases detallado, suponiendo un entorno orientado a
objetos, que muestre las relaciones existentes entre todas las clases, sera de gran ayuda a
la hora de abordar una tarea de mantenimiento. Igualmente, son muy socorridas las
tcnicas de documentacin automatica, como la solucin ;araaoc de Sun Microsystems, o
las de refactorivg.
6.3.5 Herramientas de ingeniera de ida y vuelta
Se podra decir que son un hbrido entre las herramientas CASL de bajo niel, y
las de ingeniera inersa. Lste tipo de herramientas pueden erse como la integracin de
la herramienta CASL y los entornos de desarrollo integrado orientados puramente a la
implementacin de cdigo. La particularidad que les da nombre es el hecho de que la
representacin interna que manejan de la inormacin de los distintos modelos es
directamente cdigo uente. De esta orma, la herramienta genera e interpreta cdigo en
tiempo real, puesto que es su medio de persistencia para conserar la inormacin
coneccionada por el analista.
La consecuencia directa de este modo de trabajo es una integracin completa
entre el diseno y la implementacin, puesto que el desarrollador parte del modelo
generado por la herramienta, y lo enriquece y,o modiica a medida que construye los
distintos mdulos del modelo. As, el diseno permanece riro, y se altera a medida que se
modiica el cdigo uente, mantenindose en continua actualizacin. Algunas de las
clasicas herramientas CASL orientadas a objeto como Ro.e |Rational| o 1ogetber
|Borland|, que antiguamente manejaban sus propias representaciones internas de los
modelos, se han adaptado a esta alternatia, llegando a incorporar herramientas de
compilacin e implementacin que les otorgan cualidades de IDL.
6.3.6 Herramientas de mbito especfico
No todas las herramientas CASL presentan un peril reconocible o clasiicable
dentro de alguna de las alternatias hasta ahora descritas. Suele ser el caso de las
herramientas CASL de ambito especico. Se trata de herramientas pensadas y disenadas
para dar solucin a problemas muy concretos o bien dentro de un dominio muy
especico. Suelen darse en el ambito industrial, como medio de apoyo al desarrollo de
sotware para autmatas, maquinas singulares o cualquier otro tipo de sistema de
propsito no general.
6.4 HERRAMIENTAS CASE ORIENTADAS A OBJETOS
Lidentemente, desde la aparicin de las primeras herramientas CASL en la dcada
de los 0 hasta nuestros das, la prolieracin de paquetes de este tipo ha ido creciendo
junto con las tecnologas y las metodologas. La clasiicacin y ealuacin de todas ellas
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 101
resultara sin duda un trabajo inmenso. Dentro de las que contemplan el paradigma de la
orientacin a objetos y, concretamente, el UML como lenguaje de modelado, se pueden
destacar algunas de ellas.
La Ratiovat Ro.e ue, sino la primera, una de las pioneras en el manejo, generacin y
gestin del UML. Lsto, por otro lado, era de esperar, dado que el lenguaje de modelado se
orj dentro de la misma casa que produce la herramienta ,Ratiovat,. Pese a que en un
principio manejaba su propia representacin interna de los diagramas, las ersiones actuales
persisten la inormacin de los diagramas mediante cdigo uente ,lo que la conierte en
una herramienta de las denominadas ae iaa , rvetta, complementado por sus propios
icheros de proyecto, empleados entre otras cosas para almacenar la inormacin de
localizacin de los elementos dentro del diagrama. La Ro.e orma parte de un paquete mas
amplio de herramientas que complementan el uso de la CASL dentro del ciclo de ida del
proyecto. Soporta el desarrollo en arios lenguajes orientados a objetos.
Ll 1ogetber Covtrot Cevter, en los inicios desarrollado por O oftrare y ahora
incorporado por ortava, integra as mismo arios lenguajes dentro del paradigma de la
orientacin a objetos. Ln su ltima ersin incorpora cualidades de IDL como texto
predictio, herramientas de depuracin y compilacin, etc. Ln sus inicios se present como
un conjunto de herramientas separadas, una para cada lenguaje soportado ,1ogetber],
1ogetberC, etc.,, representando tambin la inormacin del modelo en su propio ormato y
permitiendo despus una exportacin puntual con mecanismos para ingeniera inersa.
Actualmente todas ellas se encuentran integradas en una herramienta de ida y uelta.
Ln la misma lnea que las dos anteriores se encuentra el vterri.e .rcbitect,
desarrollada por de Sparx Systems |Sparx|. Lsta herramienta incorpora UML 2.0, y cubre
practicamente todo el ciclo de desarrollo de proyectos basados en tecnologa orientada a
objetos.
Pese a que las dos descritas son las mas diundidas, existe una ininidad de
herramientas comerciales dentro de la amilia de OOCASL, una mas completas que otras,
desarrollos open-source, etc.: Paraaigv Ptv., 1i.io, PorerC., etc.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 102
CAPTULO VII LNEAS DE INVESTIGACIN
La aparicin de un nueo paradigma de programacin no slo implica el desarrollo
de un lenguaje que lo implemente, o las herramientas necesarias para la construccin de
programas empleando este lenguaje. Ll ambito de lo que se conoce como vgeviera aet
oftrare, tal y como ha quedado patente a lo largo del presente estudio, se extiende mucho
mas alla de lo delimitado por los compiladores de cdigo uente.
Las metodologas de desarrollo se encuentran ntimamente ligadas a los paradigmas
de programacin. As como las metodologas orientadas al desarrollo de sotware basado
en la programacin estructurada ueron reinentadas para poder adaptarlas a la orientacin
a objetos, debera relexionarse acerca de la necesidad de adaptar las metodologas basadas
en la orientacin a objetos a las nueas tendencias de desarrollo. De igual orma, siempre
de la mano de las metodologas, las herramientas CASL que les dan soporte, y los lenguajes
de modelado sobre los que se apoyan eolucionan en la misma lnea.
Ln este trabajo de inestigacin se han ealuado las principales metodologas de
desarrollo, examinando la que en base a su mayor diusin se ha considerado mas aceptada
dentro de cada una de las amilias identiicadas, siempre prestando especial atencin a las
relacionadas con la orientacin a objetos, debido a la proximidad del paradigma POC.
Siguiendo con la introduccin realizada en estos captulos, se proponen las siguientes lneas
de inestigacin que se considera son adecuados objetios de proundizacin:
Agilizacin de metodologas clasicas
Automatizacin de procesos de desarrollo
Modelado de sistemas basados en conjuntos
Mtodos de desarrollo basados en conjuntos
Integracin con herramientas CASL
lormalizacin de requisitos mediante lgica de predicados
Lstas lneas, pese a que en esencia son independientes y complementarias, pueden
clasiicarse en dos macrolneas de inestigacin. Por un lado, las orientadas a adecuar o
eolucionar las tcnicas, notaciones y mtodos de la orientacin a objetos a la POC. Por
otro, las orientadas a solentar determinados problemas que a da de hoy han sido
identiicados en las metodologas, lenguajes de modelado y herramientas actuales. Muchas
de las soluciones a estos problemas pasaran por la combinacin de los rasgos de distintos
mtodos o tcnicas que son, en esencia, compatibles y complementarios.
7.1 AGILIZACIN DE METODOLOGAS CLSICAS
La lnea que siguen las metodologas clasicas que pretenden equiparar el desarrollo
de sotware y su gestin a los proyectos industriales iene demostrando su ineicacia debido
a diersos motios |lowler03|. Ll problema principal que presentan es la sensibilidad a los
cambios en los requisitos de los proyectos, circunstancia que, por otro lado, es mas que
recuente en el sector del desarrollo de sotware.
Ln el otro extremo se encuentra la postura de los irmantes del maniiesto agil
|Agile|, que reconocen este hecho dierencial con respecto a la industria clasica y
promueen una ilosoa distinta en el desarrollo de sotware, ilosoa que se materializa en
una serie de propuestas metodolgicas mas o menos probadas y mas o menos aceptadas.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 103
La eidente ivvaavre de estas metodologas -debida a su juentud- tiene como
consecuencia directa la presencia de restricciones que impiden su aplicacin uniersal a
todo tipo de proyectos. Los propios promotores de este tipo de metodologas reconocen
esta circunstancia.
Ln el trmino medio de estos dos extremos, se encuentra la alternatia de agilizar
aquellas metodologas que, por otro lado, han demostrado a lo largo de arios anos su
eicacia en determinados aspectos del ciclo de ida de un proyecto. Ln |lirsch| Michael
lirsch propone la agilizacin del mtodo uniicado de Rational ,RUP,, mientras que en
|lowler03| Martin lowler se cuestiona incluso si debe ser RUP clasiicada como
metodologa agil, citando a distintos autores que deienden la posible agilizacin de esta
metodologa.
La agilizacin de metodologas es una lnea de inestigacin muy reciente que se
encuentra en plena ebullicin. Desde los primeros resultados publicados con XP, el mundo
acadmico se ha comenzado a cuestionar las posibles aportaciones de esta nuea ilosoa a
las metodologas clasicas de desarrollo de sotware. Ln el caso concreto de la POC, hay que
subrayar que uno de las ideas motores sobre las que se esta desarrollando es precisamente
conseguir una menor ulnerabilidad del sotware ante los cambios puntuales en los
requisitos, mediante una mayor lexibilidad del cdigo.
7.2 AUTOMATIZACIN DE PROCESOS DE DESARROLLO
Ln los ltimos anos, el boom tecnolgico y de Internet ha dado lugar a un mercado
muy competitio, donde las empresas cliente alimentan al enjambre de empresas
proeedoras y desarrolladoras de sotware. Cuando se habla de competitiidad en empresas
de desarrollo, se habla de tiempos de entrega y costes de los proyectos. Los ciclos de
desarrollo de sotware se han isto ajustados de tal orma que la mas mnima incidencia
supone un retraso no asumible por parte del equipo de desarrollo. Una de las tcnicas que
orece mejores resultados a la hora de reducir los costes del proyecto es la automatizacin
de ciertas partes del proceso de desarrollo sotware |Lanin03|.
Ln esta ltima categora se pueden englobar un amplio conjunto de tcnicas que
automatizan algunas de las distintas actiidades necesarias durante la ejecucin de un
proyecto de desarrollo sotware. Algunas de las mas destacables y,o habituales son, por
ejemplo, trabajar con plantillas de cdigo, la automatizacin de ciertas tareas mecanicas
,compilacin, empaquetado, integracin continua, despliegue, etc., con herramientas como
Makeile o AN1, el empleo de procesos por lotes o la generacin automatica de cdigo.
Los procesos de automatizacin de cdigo tienen sus orgenes en la aparicin de las
primeras herramientas CASL en el mercado. La generacin automatica de cdigo a partir
de los diagramas generados por el analista reduce los tiempos de desarrollo y
mantenimiento, y limita la aparicin de errores tipograicos en el cdigo. Ln esta lnea han
aanzado tanto los IDLs actuales, como las propias herramientas CASL.
Las posibilidades de automatizacin ienen condicionadas por muchos actores,
algunos de ellos dependientes del tratamiento que dictamine la metodologa aplicada y de la
capacidad de la notacin empleada para el modelado del sistema en construccin.
Lsta lnea de inestigacin ha sido muy prolica durante los ltimos anos. Como
eento signiicatio de esta hecho, la OMG |OMG| public el MDA ,Moaet Drirev
.rcbitectvre, |MDA|, un modelo de arquitectura basado en los estandares de OMG que
pretende disociar la lgica de negocio de la plataorma de implementacin de las
aplicaciones.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 104

Iigura 34 Arquitectura Model Driven Architecture
Lsta y otras tcnicas se encuentran ligadas ,y limitadas, por el alcance y capacidad
de representacin de los lenguajes de modelado.
7.3 MODELADO DE SISTEMAS BASADOS EN CONJUNTOS
La principal particularidad de la POC que la distancia de la orientacin a objetos es
precisamente el concepto de cov;vvto. Ll elemento cov;vvto, tal y como se ha descrito en el
captulo segundo del presente trabajo, carece de tipologa estricta, y ademas, no cuenta con
mtodos directamente asociados.
Lsta circunstancia inalida el lenguaje de modelado estandarizado para la
representacin de sistemas orientados a objetos ,UML, para el modelado con POC. Sera
necesario establecer un nueo lenguaje de modelado que contemple estas nueas
estructuras, o bien disenar una extensin de la especiicacin UML actual que permita dicha
representacin de orma compatible con las actuales caractersticas del lenguaje de
modelado. Algunos de los puntos donde se hace patente esta incompatibilidad son:
t aiagrava ae cta.e., dado que no se cuenta con ninguna notacin posible para la
representacin del los conjuntos. As mismo, en el diagrama de clases UML no es
posible introducir un mtodo no asociado a ningn objeto -algo normal, por otro lado,
dado que la asociacin mtodo-objeto es uno de los pilares basicos sobre los que se
basa el paradigma.
o. aiagrava. ae ivteracciv, dado que no es posible representar una accin comenzada o
dirigida por un conjunto.
Diagrava. ae ob;eto., puesto que no es posible especiicar a que conjunto o conjuntos
pertenece el objeto, ni las transiciones entre conjuntos que pueden deriarse de la
ejecucin de un escenario.
Diagrava. ae e.taao., actiriaaa y cualquier otro donde pueda ser necesario establecer o
especiicar la pertenencia de un objeto a un conjunto determinado en un momento
dado.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 105
Ll lenguaje de modelado y su especiicacin tiene gran releancia a la hora de
automatizar procesos de desarrollo. La normalizacin de escenarios permite dar soluciones
normalizadas a problemas conocidos.

Iigura 3S Representacin de clase vs conjunto

La incorporacin de conjuntos por parte de un lenguaje de modelado es
conceptualmente prximo al manejo de roles propuesto por Reenskaug en OORAM
|Reenskaug96|, cuyas ideas pueden ser un punto de partida alido en la labor de normalizar
la representacin de los conjuntos propuestos por la POC.
7.4 MTODOS DE DESARROLLO DE SISTEMAS BASADOS EN CONJUNTOS
Ln el presente estudio se han ealuado las metodologas mas representatias de
cada amilia metodolgica, respondiendo la clasiicacin a la naturaleza de los proyectos
que estan orientadas a guiar. Las clasiicadas como orientadas a objetos, y basadas en roles
son las que, por proximidad conceptual con la POC, suponen sin duda el mejor punto de
partida para alcanzar un nueo modelo metodolgico que permita desarrollar proyectos
basados en POC.
Las cualidades del lenguaje 1evv y en general del paradigma POC sugieren un
cambio en la ilosoa del tratamiento de las reglas de negocio que hasta ahora se aplica en
los procesos de desarrollo de sotware. La disociacin entre entidad y mtodo que deiende
la POC inita a realizar un tratamiento especico para dichos mtodos, concretamente
aquellos que satisaran las reglas deducidas del estudio del dominio del sistema.
Ln esencia, se trata de alorar nueas tcnicas de tratamiento de los requisitos y
reglas de negocio del dominio. La actual inculacin entre reglas y arquitectura sotware
limita la lexibilidad del sistema. Lsto tiene como consecuencia el importante impacto que
supone la ariacin de una de estas reglas en el sistema, algo que, por otro lado, es bastante
habitual en el mundo real. Algunas alternatias LRP como SAP basan sus soluciones en el
modelado estandar de procesos. Los mdulos uncionales son nicos para todas las
implantaciones del producto. La adaptacin de cada mdulo a las circunstancias especicas
del dominio se consigue gracias al eleado grado de parametrizacin que presentan. Lsto
en deinitia no es mas que la normalizacin de la regla a un modelo comn y la
externalizacin de los ajustes al dominio.
7.5 INTEGRACIN CON HERRAMIENTAS CASE/IDES
Ln la sinergia existente entre metodologas y herramientas CASL radica el xito o
racaso tanto de unas como de otras. As, no es concebible el desarrollo o adaptacin de
metodologa alguna si el resultado de dicho estudio no esta soportado por una herramienta
Atributo 1
Atributo 2
Atributo 3

Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 106
CASL que permita su aplicacin, la automatizacin del modelado y, si es posible, de parte
del desarrollo.
Ll desarrollo de herramientas CASL es una lnea de inestigacin en continua
eolucin, irmemente ligada a la automatizacin de procesos de desarrollo y a la propia
eolucin de lenguajes de modelado y metodologas de desarrollo. Las tendencias mas
recientes en las herramientas de este tipo es la usin CASL-IDL, de orma que la misma
herramienta permita modelar, disenar e incluso codiicar el producto en desarrollo.
Las caractersticas deinitorias de la POC requieren de la adaptacin de los actuales
modelos de herramientas -tanto CASL como IDLs- para adecuarlas al manejo y gestin de
conjuntos y mtodos de negocio independientes de entidad. Ll desarrollo de lenguajes
isuales de desarrollo cobra mayor importancia al trabajar con evtiaaae. que pueden cambiar
de tipo y propiedades en base al conjunto al que pertenezcan en un momento dado de su
ciclo de ida.
7.6 FORMALIZACIN DE REQUISITOS MEDIANTE LGICA DE PREDICADOS.
Las metodologas de desarrollo existentes arrastran el problema de la prdida de
inormacin durante la abstraccin desde los comienzos de la ingeniera del sotware. Si
bien la aparicin de las primeras metodologas orientadas a objetos pali en parte esta
circunstancia mediante la aproximacin del analisis y el diseno, las transormaciones de los
conceptos del mundo real en piezas normalizadas y manejables por computadoras, los
razonamientos seguidos y las abstracciones aplicadas se quedan en la mente del analista que
las realiza.
Ll desprecio por la ase de analisis y por los resultados de la misma una ez
desarrollado el diseno del sistema supone un inconeniente a la hora de mantener el
producto. RUP llega incluso a considerar actible el abandono del mantenimiento del
modelo de analisis de un proyecto |Jacobson00|. Como consecuencia de esta circunstancia,
el usuario de la documentacin producto de la metodologa carece de la inormacin
necesaria para comprender el porqu de determinados modelos, conclusiones o
abstracciones, quedandole slo la opcin de aeavcir el razonamiento del analista autor, lo
cual supone una uente de error importante.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 107

Iigura 36 Iormalizacin de requisitos
Las lneas de inestigacin mas populares en este aspecto buscan la solucin a este
salto entre lo abstracto y lo estructurado, entre el sentido comn y lo normalizado en la
ormalizacin de los requisitos del proyecto mediante lgica de predicados |luth00|. Dicha
ormalizacin abre un amplio abanico de posibilidades de control, seguimiento y
automatizacin de tareas, actiidades responsabilidad todas ellas de la metodologa de
desarrollo empleada. La integracin de las tcnicas aanzadas de ormalizacin lgica en las
metodologas actuales es una lnea de inestigacin incipiente, cuyos resultados pueden
suponer aances signiicatios en la eolucin de la ingeniera del sotware.
7.7 CONCLUSIONES
Ante la aparicin del la POC, se torna necesario realizar una serie de adaptaciones e
innoaciones en algunos de los aspectos de la ingeniera del sotware. Ll punto de partida
adecuado es, sin duda, el paradigma de la orientacin a objetos, y todas las tcnicas sobre la
que se sustentas sus proyectos. No obstante, la simple adaptacin de las tcnicas OO a la
POC implicara heredar no slo las tcnicas que han demostrado eectiidad, sino tambin
aquellos aspectos que son uente habitual de problemas en los proyectos OO. Las
adaptaciones o renoaciones son momentos de obligada relexin para abordar problemas
ya maniiestos. Lsta tarea puede realizarse bien mediante el desarrollo e incorporacin de
nueas ideas, o bien mediante la adopcin de algunas ya probadas en ambitos similares.
La proundizacin en los puntos dbiles de la ingeniera del sotware, algunos
sintetizados en las lneas de inestigacin anteriormente propuestas, ha sido ya en parte
abordada por distintos estudios, cuyas conclusiones se han limitado a ambitos muy
especicos del proceso de desarrollo de sotware. La aportacin de nueos enoques y
soluciones, junto con la ealuacin, eolucin y adopcin de algunas de estas conclusiones
supone una lnea de trabajo an en crecimiento y, en el caso concreto de la POC, necesaria.
Lenguaje
NaluiaI
Ingcnicra
dc
Fcquisiios
Analisis Discno Inlcncniacion
Alsliaccin
Lenguaje
NaluiaI
Infoinacin
Lsliucluiada
Analisis Discno Inlcncniacion
Alsliaccin
Infoinacin
Lsliucluiada
Ingcnicra
dc
Fcquisiios
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 108
CAPTULO VIII GLOSARIO
8.1 DEFINICIONES
8.1.1 Requisito
Los requisitos son caractersticas que debe tener el sistema |Bruegge02|. Ln base
a su naturaleza, se pueden clasiicar en:
funcionales: el requisito es un area de uncionalidad que debe soportar el
sistema.
no funcionales: una restriccin sobre la operacin del sistema. Lspeciican
propiedades del sistema, como restricciones del entorno o de la
implementacin, rendimiento, dependencias de la plataorma, acilidad de
mantenimiento, extensibilidad, y iabilidad. |Jacobson00|.
8.1.2 Tarea
Una tarea representa una unidad atmica de trabajo que puede ser administrada
|Bruegge02|. Las tareas consumen recursos, dan como resultado productos de trabajo y
dependen de productos de trabajo que son producidas por otras tareas. Una tarea es
asignada por el administrador del proyecto a un desarrollador. Ll desarrollador la realiza,
y el administrador superisa su progreso y correcta inalizacin.
8.1.3 Recurso
Los Recursos son el actio del que se dispone para llear a cabo el trabajo. Un
recurso puede ser tiempo, personal o equipos.
8.1.4 Actividad o Fase
Una actiidad es el conjunto de tareas que se realizan con un propsito
especico |Bruegge02|, como la obtevciv ae reqvi.ito., actiidad cuyo propsito es deinir
con el cliente lo que hara el sistema a desarrollar. La evtrega es otra actiidad cuyo in es
instalar el sistema en el entorno de produccin. La aavivi.traciv es un actiidad cuyo
propsito es superisar y controlar el proyecto de orma que cumpla sus objetios
,tiempo de entrega, calidad, presupuesto, etc.,. Las actiidades pueden estar compuestas
por otras actiidades. Por ejemplo, la actiidad de evtrega puede comprender la de
iv.tataciv y la de forvaciv de los usuarios.
8.1.5 Notacin
Una notacin es un conjunto de reglas graicas o textuales para representar un
modelo |Bruegge02|. Ll alabeto romano es una notacin para representar palabras. La
notacin constituye la parte graica de los modelos, es la sintaxis graica del lenguaje de
modelado |lowler03b|. As, por ejemplo, la notacin del diagrama de clases en
orientacin a objetos deine como se han de representar los elementos y conceptos
pertenecientes al modelo, como clases, asociaciones, multiplicidad, etc.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 109
8.1.6 Lenguaje de Modelado
Conjunto de notaciones empleadas para representar las distintas istas del
modelo de un sistema sotware.
8.1.7 Paquete
Ln trminos de notaciones o lenguajes de modelado, el concepto de aqvete
deine una construccin basada en la agrupacin de distintos elementos que permita
tratar el conjunto que deine como una unidad de mas alto niel
8.1.8 Metodologa de Anlisis
Conjunto de mtodos que cubren las actiidades orientadas al analisis del
dominio de un sistema.
8.1.9 Metodologa de mbito especfico
Metodologa orientada a desarrollar proyectos cuya actiidad se reduce a un area
limitada y concreta de dominio. Ls de ambito especico, por ejemplo, la metodologa
OlDM, orientada al desarrollo de sistemas de inormacin basados en tecnologas
\LB.
8.1.10 Lenguaje de propsito especfico
Lenguajes desarrollados para el modelado de dominios muy concretos. Por
ejemplo, los lenguajes propietarios para la programacin de autmatas industriales.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 110
CAPTULO IX REFERENCIAS
|Pressman91| Ingeniera del Sotware. Un enoque practico. 1ercera Ldicin.
Roger S. Pressman, McGraw lill
|NAUR69| Sotware Lngineering: A Report on a Conerence ponsored by the
NA1O Science Comit. Naut, P. y B. Randell. NA1O 1969
|Rumbaugh91| Object-Oriented Modeling and Design. J. Rumbaugh, M.Blaha, \.
Premerlani, and V. l. Lddy. Prentice-lall, 1991.
|Dorman 9| Sotware Lngineering. Dorman and R. l. 1hayer, editors.
ILLL Computer Society Press, 199.
|Sommerille02| Ingeniera de Sotware. Sexta Ldicin. Ian Sommerille
Addison \esley 2002
|Jacobson00| Ll Proceso Uniicado de Desarrollo de Sotware. Iar Jacobson,
Grady Booch, James Rumbaugh Addison \esley 2000
|Bruegge02| Ingeniera de Sotware orientado a objetos. Bernd Bruegge, Allen
l. Dutoit Prentice lall 2002
|OMG98| OMG Uniied Modeling Language Speciication. Object
Management Group, lramingham 1998
|Jacobson92| Object-Oriented Sotware Lngineering: A Use Case Drien
Approach. Iar Jacobson ,Author,, Magnus Christerson ,Author,,
Patrik Jonsson ,Author,, Gunnar Oergaard ,Author,, Publisher:
Addison-\esley Pub Co, 1st edition ,June 30, 1992,. ISBN:
0201544350
|JUnit| www.junit.org
|Cactus| jakarta.apache.org,cactus,
|Jackson5| Principles o Program Design. Michael A. Jackson, Academia Press.
195
|Cameron83| JSP & JSD: 1he Jackson Approach to Sotware Deelopment. J.
R. Cameron ILLL CS Press, 1983
|Cameron88| 1he Modelling Phase o JSD. J. R. Cameron. Inormation and
Sotware 1echnology, Volume 30 Number 6, pp 33-383,
July,August 1988
|loldoc03| http:,,wombat.doc.ic.ac.uk,oldoc,
|lowler03| www.martinowler.com
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 111
|Acebal02| Lxtreme Programming ,XP,. Un nueo mtodo de desarrollo de
sotware. Csar lernandez Acebal, Juan Manuel Cuea Loelle.
|Rae03| Real Academia de la Lengua Lspanola. http:,,www.rae.es
|lowler03b| UML Distilled: A Brie Guide to the Standard Object Modeling
Language, 1hird Ldition. Martin lowler. Addison \esley, 2003.
ISBN 0-321-19368-
|Ootlab| Object Oriented 1echnology Laboratory Research Group.
www.ootlab.unioi.es. Uniersity o Oiedo
|OMG| Object Management Group http:,,www.omg.org
|CORBA| CORBA,IIOP Speciication. Object Management Group.
http:,,www.omg.org,technology,documents,ormal,corba_iiop.
htm
|Booch93| Object-Oriented Analysis and Design with Applications ,2nd
Ldition,. Grady Booch ,Author,. Addison-\esley Pub Co, 2nd
edition ,September 30, 1993, ISBN: 0805353402
|Rational| Rational Sotware. http:,,www.rational.com
|Macclure 85| Case is Sotware Automation. Carma McClure. Pearson Lducation
POD, 1st edition ,March 11, 199, ISBN: 0131193309
|Kendall91| Analisis \ Diseno De Sistemas 3'. Ldicin. Kendall. Prentice lall
,a Pearson Lducation company,, ,August 1, 1991, ASIN:
96888014
|Jarzabek98| 1he case or user-centered CASL tools. Stan Jarzabek, Riri luang.
Communications o the ACM archie
Volume 41 , Issue 8 ,August 1998,. ISSN:0001-082
|Deis96| OORam: Modelos de Roles. Ricardo Deis INlOOP`96. Spanish
Conerence on Object 1echnology. Alicante 1996
|Reenskaug96| 1he OOram Sotware Lngineering Method. 1ryge Reenskaug, Per
\old y Odd Arild Lehne, 1996, Manning Publications, 1-884-
10-4 ,Prentice-lall, 0-13-452930-8,
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 112
|Garcia98| Una experiencia Practica con la arquitectura de tres modelos
OORam. Garca Molina, Manuel L. Acacio Sanchez, Gins Garca
Mateos. IV Congreso sobre 1ecnologias de objetos. Deusto, 1998.
|Beck89| Laboratory or teaching object oriented thinking. Ken Beck, \.
Cunningham OOPSLA 89. Sigplan notices, ol 24 October 1989.
|Garca02| 1ransorming the OOram 1hree-Model Architecture into a UML-
based Process. Garca Molina, Maria Jos Ortn, Begona Moros,
Joaqun Nicolas. JOURNAL Ol OBJLC1 1LClNOLOG\
Published by L1l Zurich, Chair o Sotware Lngineering JO1,
2002
|Lanin03| Automatizacin de Procesos de desarrollo. Daniel lernandez
Lanin, Aquilino A. Juan luente, Ral Izquierdo Castanedo,
Benjamn Lpez Prez. II Congreso Internacional de la Sociedad
de la Inormacin y del Conocimiento. 2003. Madrid.
|DeMarco9| Structured analysis and system speciication. 1om DeMarco.
Serie,s,: \ourdon Press computing series. New Jersey \ourdon
Press, 199 ISBN: 0138541345
|\ard85| Structured deelopment or real-time systems. \ard, Paul 1,
Mellor, Stephen J, New Jersey : \ourdon Press, 1985. ISBN:
01385484x
|latley88| Strategies or real-time system speciication. latley, Derek J.
Pirbhai, Imtiaz A Dorset louse, 1988. ISBN: ,0932633110
|\ourdon9| Structured Design. \ourdon, L. & Constantine, L Lnglewood
Clis, NJ: Prentice lall, 199.
|Labrana| Marcos de Modelado en la Ingeniera del Conocimiento,
CommonKADS y el Diseno de un Sistema para Nutricin y
Diettica. Cecilia Labrana, Pedro Salcedo L. Ricardo Cid l., \usse
larran L.
|Daid93| Oeriew o Knowledge Acquisition 1ools. J. M. DAVID, J.P.
KRIVINL & R SIMMONS.Second Generation Lxpert System.
Springer-Verlag.
|lenao 9| Metodologa para el Desarrollo de la 1ecnologa de Sistemas
Intelimedios. M. lenao. 1esis de la Maestra en Gestin de
1ecnologas, Uniersidad Pontiicia Boliariana, Medelln,
Colombia. 199. 238 p.
Desarrollo de una Metodologa para un nuevo Paradigma de Desarrollo de Software
Daniel FERNNDEZ LANVIN Pgina 113
|Cadas96| |Use o CommonKADS Methodology in Knowledge Nased
Systems. C. Cadas, N. Parthenios. Catalyst - Deelopment. linal
Report. 1996. 54 p.
|Bauer 92| Interpretation Models or KADS. C. Bauer, \. Karbach ,eds.,.
Proceedings o the 2nd KADS User Meeting ,KUM92,. Munich.
GMD Report No. 212. 1992.
|Agile| Maniiesto gil. www.agilemaniesto.org
|lirsch| Making RUP Agile. Michael lirsch. Conerence on Object
Oriented Programming Systems Languages and Applications.
OOPSLA 2002. \ear o Publication: 2002 ISBN:1-58113-41-1
|MDA| http:,,www.omg.org,mda,
|luth00| Logic in Computer Science. Modelling and reasoning about
systems. Michael R. A. luth, Mark D. Ryan Cambridge Uniersity
Press 2000. ISBN 0-521-65602-8.
|lolub90| Compiler Design in C. Allen I lolub. Prentice lall 1990. ASIN
0131550454.
|Aho85| Compilers: Principles, 1echniques, and 1ools. Alred V. Aho, Rai
Sethi, Jerey D. Ullman. Addison \esley Publishing Company,
,October 1, 1985,. ISBN: 0201100886.
|Sparx| Sparx Systems - http:,,www.sparxsystems.cl,