Capa11 PDF

&ULWHULRV H &RQYHQFLyQV HQ $UTXHROR[tD GD 3DLVD[H
7HFQRORJtDV GH OD ,QIRUPDFLyQ \ 3DWULPRQLR &XOWXUDO
8QD 0HWRGRORJtD ,QWHJUDO 2ULHQWDGD D 2EMHWRV SDUD 'HVDUUROOR GH 6RIWZDUH

Csar A. Gonzlez Prez
/DERUDWRULR GH $UTXHROR[tD H )RUPDV &XOWXUDLV *,$U3D 8QLYHUVLGDGH GH 6DQWLDJR GH &RPSRVWHOD Primera Edicin, Diciembre de 1999
&$3$
&ULWHULRV H &RQYHQFLyQV HQ $UTXHROR[tD GD 3DLVD[H
FRPLWp HGLWRULDO
Felipe Criado Boado, LAFC, IIT, USC (director) Xess Amado Reino, LAFC, IIT, USC (secretario de TAPA) Csar Parcero Oubia, LAFC, IIT, USC (secretario de CAPA) Csar A. Gonzlez Prez, LAFC, IIT, USC Sergio Martnez Bogo, LAFC, IIT, USC Mara Pilar Prieto Martnez, LAFC, IIT, USC Sofa Quiroga Limia, LAFC, IIT, USC Anxo Rodrguez Paz, LAFC, IIT, USC
FRPLWp DVHVRU
David Barreiro Martnez, LAFC, IIT, USC Francisco Burillo Mozota, Seminario de Arqueologa y Etnologa Turolense Isabel Cobas Fernndez, LAFC, IIT, USC Ramn Fbregas Valcarce, Dpto. de Historia I, Fac. de Xeografa e Historia, USC Faustino Infante Roura, D. X. do Patrimonio Cultural, Xunta de Galicia M del Carmen Martnez Lpez, S. T. de Patrimonio Histrico, Diputacin de A Corua M Isabel Martnez Navarrete, Centro de Estudios Histricos, CSIC Victoria Villoch Vzquez, S. T. de Patrimonio Histrico, Diputacin de A Corua
GLUHFFLyQ GH FRQWDFWR
Secretara de CAPA Laboratorio de Arqueologa y Formas Culturales Grupo de Investigacin en Arqueologa del Paisaje Instituto de Investigaciones Tecnolgicas Universidade de Santiago de Compostela Apdo. de Correos 994 15700 Santiago de Compostela Galicia, Espaa Tel. 981 590555 Fax 981 598201 E-mail phpubs@usc.es Web http://www-gtarpa.usc.es/CAPA
HMHPSODUHV
Cualquier persona interesada en recibir ejemplares de esta serie puede ponerse en contacto con la Secretara de CAPA mediante el telfono o e-mail que figuran arriba.
(GLWD Laboratorio de Arqueoloxa e Formas Culturais (GIArPa), IIT, USC 'HSyVLWR /HJDO C 1871 1997 ,6%1 84-699-1337-9
7$%/$ '( &217(1,'2

Introduccin......................................................................................................................5 Conceptos Bsicos ............................................................................................................5 Procedimiento...................................................................................................................7 Obtencin de Requisitos ...........................................................................................8 Control de Cambios...................................................................................................9 Anlisis de Alto Nivel .............................................................................................10 Diseo Arquitectnico de Alto Nivel ....................................................................12 Estudio Tecnolgico ................................................................................................13 Planificacin..............................................................................................................13 Confeccin de la Documentacin de Usuario ......................................................14 Anlisis de Bajo Nivel .............................................................................................15 Diseo Arquitectnico de Bajo Nivel ....................................................................16 Diseo de Detalle .....................................................................................................16 Diseo de Persistencia.............................................................................................17 Codificacin ..............................................................................................................18 Sincronizacin ..........................................................................................................18 Pruebas Finales.........................................................................................................19 Notacin ..........................................................................................................................19 Texto Libre ................................................................................................................19 Texto Estructurado ..................................................................................................19 Diagramas de Eventos.............................................................................................19 Diagramas de Clases................................................................................................20 Diagramas de Estados de Servicios .......................................................................21 Bocetos de Elementos de Interface de Usuario ....................................................22 Diagramas de Componentes ..................................................................................22 Diagramas de Colaboracin ...................................................................................22 Diagramas de Visibilidad .......................................................................................23 Seudo-cdigo ............................................................................................................23 Cdigo Fuente ..........................................................................................................24 Glosario ...........................................................................................................................24 Bibliografa......................................................................................................................26
),&+$ 7e&1,&$
DSRUWDFLRQHV
Pablo Criado, Pablo Gonzlez Nascimento, M del Mar Bveda, Roberto Gmez y Javier Cancela han contribuido especialmente a los resultados mostrados en este volumen. Gracias a todos ellos.
SUR\HFWRV
La metodologa Metis ha sido o est siendo utilizada en el desarrollo del sistema de informacin Adibal para la Consellera de Cultura (Xunta de Galicia), as como en el proyecto de investigacin aplicada BlueMoon (Laboratorio de Arqueoloxa e Formas Culturais).
UHIHUHQFLDV DGPLQLVWUDWLYDV
La metodologa de desarrollo de software expuesta en este volumen se incluye tambin como parte de la tesis doctoral del autor.
ILQDQFLDFLyQ
Financiacin del proyecto: Laboratorio de Arqueoloxa e Formas Culturais (GIArPa). Financiacin de la edicin: Laboratorio de Arqueoloxa e Formas Culturais (GIArPa).
UrpytthqryhDshpvyQhvv8yhy!) VhHrqytthDrthyPvrhqhhPiwrhh9rhyyqrTshr
86Q6 UrpytthqryhDshpvyQhvv 8yhy!)VhHrqytthDrthyPvrhqhh Piwrhh9rhyyqrTshr 8ph6BiyrQpr Ghihvqr6rythrAh8yhv VvrvqhqrqrThvhtqr8ryh Qvrh@qvpvy
,1752'8&&,1
La metodologa Metis ha surgido como resultado de la evolucin del Mtodo Fusion Adaptado (MFA), una variacin del mtodo Fusion original (Coleman HW DO 1994) confeccionada y puesta en prctica en el Laboratorio de Arqueologa y Formas Culturales desde 1997. En concreto, Metis se ha beneficiado sustancialmente de los desarrollo tericos de Gonzlez 1999, as como de los trabajos presentados en Malan HW DO 1996 (especialmente Cotton 1996). Tambin han sido fundamentales los trabajos de Meyer 1997 y McConnell 1996. Las principales novedades que Metis aporta respecto al MFA son: Integracin de las labores de diseo y construccin del interface de usuario. Integracin de las labores de diseo y construccin de almacenes persistentes (bases de datos). Integracin de las labores de confeccin de documentacin de usuario. Numerosas mejoras semnticas puntuales. Soporte de trabajo en paralelo, contemplando la realizacin simultnea de diferentes funciones y/o ciclos de desarrollo. Alta modularidad, permitiendo extensiones especficas segn las infraestructuras elegidas (lenguajes, sistemas de bases de datos, etc.). Soporte directo para medicin del sistema.
5(680(1
Este trabajo ofrece una descripcin completa y exhaustiva de la metodologa Metis, tanto de la notacin utilizada como de los procedimientos establecidos.
$%675$&7
This work offers a complete and exhaustive description of the Metis methodology, regarding both its process and its notation.
3$/$%5$6 &/$9(
Metodologa de desarrollo de software. Orientacin a objetos.
.(<:25'6
Software development orientation. methodology. Object-
A su vez, las principales novedades que el MFA aport en su momento con respecto al mtodo Fusion fueron: Incorporacin de una fase de obtencin de requisitos. Integracin del procedimiento en un ciclo de vida evolutivo.
Creemos que las novedades enumeradas constituyen una diferencia notable entre Metis y las metodologas que se hallan publicadas en la actualidad, tales como Rumbaugh HW DO 1991, Booch 1994 o Coleman 1994. Es necesario tener en cuenta que Metis est todava en desarrollo, y la versin que se publica en este trabajo no constituye en ningn caso un producto finalizado.
&21&(3726 %6,&26
Metis ha sido construida como un sistema de informacin, en trminos de componentes, servicios e interfaces. En concreto, Metis extiende la
86Q6
dualidad convencional notacin/procedimiento mediante la incorporacin de WUHV QLYHOHV GHVFULSWL YRV diferentes: )XQFLyQ Una funcin es un tipo de tareas que se pueden realizar dentro de la prctica general del desarrollo de software. 5HVXOWDGR Un resultado es un producto que se crea a partir de la ejecucin de una funcin. Cada funcin puede dar lugar a diferentes resultados. 'RFXPHQWR Un documento es una concrecin material de un resultado. Un mismo resultado puede manifestarse a travs de distintos documentos.
en un sistema totalmente funcional. Puede verse una descripcin completa de cada funcin en 3URFHGLPLHQWR, as como una explicacin completa de las secuencias de funciones recomendadas. Por otra parte, y as como el procedimiento de Metis se describe mediante el nivel descriptivo funcin, su QRWDFLyQ viene dada por el nivel descriptivo documento. En concreto, los tipos de documentos que pueden generarse durante un desarrollo con Metis son los siguientes:
Iir 9rpvpvy
UrGvir Ur@phq
De este modo, el SURFHGLPLHQWR JHQHUDO de Metis est constituido por las funciones de la siguiente tabla:
Iir Piwrv
PirpvyqrSrv v 8yqr8hiv 6iyvvqr6yIvry 9vrx6vrpyvp qr6yIvry @qvUrpyytvp Qyhvsvphpvy
8srppvyqryh9 prhpvyqrVh v 6iyvvqr7hwIvry @yhih qry rrptsvp qr phqh prr h pv 9vrx6vrpyvp 9vrypprvrthrqrphqhprrh qr7hwIvry pvrhprphyhqrphq 9vrxqrQrvrpvh @hiyrpryrphvrqvhryphyryhvsh pvy hrwhqh ry vrh qi r hyhprhqh qr shrvrrrprhqhrvrr 9vrxqr9rhyyr @yhihqrypprqrphqhrhpvyphhqr rvyrrhqhvryqrivh 8qvsvphpvy Uhqpvhpyqvtsrrryqryqr yhrhpvy h v yrrh Tvpvhpvy 8ihryhspvhyvqhqhxhqvqhhyvrhrhqr phqhrvqpvrryprqrqrhyyyhhvhpv rrruhhqpvq QrihAvhyr 8hh ry vrh svhy p y rvv rhiyrpvq hhryv
7DEOD )XQFLRQHV GH 0HWLV Es preciso sealar que las funciones enumeradas no han de ser acometidas por el orden en que se citan, si no que su disposicin a lo largo del tiempo puede ser compleja, y ha de obedecer siempre a una planificacin especfica. En concreto, el ciclo de vida de Metis es HYROXWLYR, es decir, el sistema a construir es incrementalmente implementado en sucesivos ciclos hasta concluir
9rpvivrysvrhspvhy spvhyrr vpyrqphrhqrirrphhqruhprihwp pqvpvrrvpvh 6rth r y phiv rhyvhq ir y rvv qryvrhrwqvphhyqrhyytyihyqryv @yhihqrytrrhyqryvrh hpvrh iyrpvrqrvvpprhyrhhvqryspvh yr 9vrypprvrthrqryvrhhpv rhprphyhqrphqhhvyrrhpvy @yrtv yh rpytth h vyvh r yh vyrrhpvy qry svrh 9vvivyhspvhyvqhqqrysvrhrpw qrphhprtvph vpyrq hhphqh vvqhq yh qrrqrpvh p y qri prqrpvh pyrvvqryvrh Srqhphshrhyhqprhpvyqrhv
Uryvir Ur qvr r h rvr qr rt thsrrppvrrqrrvhqh 9vhthhqr 9vhthh qr hh rhy qr @r rrrrhprvrh 9vhthhqr8yh 9vhthh qr pyhr ryhpvr r yrrrhyhrphqr vrhprr 9vhthhqr@h 9vhthh qr rhq qry vrh qqrTrvpv qhr yh rwrppvy qr rvpv vqvphqy hir qr phqh r hqy@VDhpvhq 7prqrrhhphqqr qvi 7prqr@yr rqrDrshpr yt @VD vpyrq pyr qrVhv 9vhthhqr8 9vhthh qr prr ryhpv rr rrrhyhrphqr vrhprr 9vhthhqr8yh 9vhthh qr iwr ryhpvr ihpvy pyvrrrvq rprpvhpvy r rh py r qpr h r hpvy 9vhthhqrWvviv 9vhthh qr iwr pyhr r yvqhq rhpyhpyhrrqrhppr qrhh Trqpyqvt Trqpyqvtrvshy 8yqvtArr 8yqvtsrrqrthhihrqr qhvrshprrp
7DEOD 7LSRV GH GRFXPHQWRV HQ 0HWLV Cada tipo de documento concreto posee una notacin especfica asociada, que puede verse en 1RWDFLyQ. Finalmente, el nivel descriptivo resultado proporciona el mecanismo natural de enlace entre procedimiento y notacin, ofreciendo al mismo tiempo un adecuado lugar de conexin para extensiones de la metodologa. Los resultados que pueden obtenerse al realizar las funciones de Metis son los siguientes:
Iir 9rpvpvy
Irprvqhqr 9vppvhvqryTv rh SrvvqryTv rh Qrhqr8h iv
9rhqh vvpvhy hr qry s hvqryvrh 9rsvvpvrqrypprhrwh qryvrh 8hhprvhpvy spvhy rvpvh spvhy qry s vrh Ch qrvpyvhyvhvvhqhqrrv vhyvp Qrh hh rhyvh phiv rrptsvphyrvvqryvrh
&
Iir
HhhyqryVhv 8hqrV Hqryqr8yhr qry9vv Hqryqr8yhr qryTvrh HqryqrDrshpr qryTvrh Hqryqr6v rphqryTvrh GvhqrSrp Urpyytvp 8wqr8h hprtvph
QyhBrrhyqr Uhihw Hqryqr8yhr qry8rr HqryqrDrshpr qry8rr Hqryqr6v rphqry8 rr HqryqrQrv rpvh Hqry9vivpqr yhPrhpvy HqryqrWvvivyv qhq HqryqrDrshpr qryh8yhr 8yqvtArr
Dsrqr9vsrr pvhAvhyr
9pr qvrxhq hh rrxh py h ry vrh hy hv svhy qryv 8h trpvp qr vyvhpvy qry s vrh Hqry qr pyhr ryhpvr yr qryqvvqrhyvphpvy Hqry qr pyhr ryhpvr yr qry vrh h pv @ i pw qry Hqry qr 8yhr qry 9vv Hqry qr hpr rr rvpv rhpvrqryvrhhpv Hqryqrprrqryvrhh pv Gvh qr yh urhvrh yrthwr vrhqrihrqrqhuhqhr rrptsvphvshrphrp yytvphhvyvh Gvh qr iyr spvhyr p prhyr qry vrh h pv qrhqrt~yh rprpvh qr p ppvy r vpyrq vshpvy hprph qr vrqrrqrpvh rr ryyqrryhpvrpyrv v hyvp phr Srvv qry Tvrh Qyhvsvphpvy trrhy qr y pvpy qr qrhyy h hprr vpyrq vshpvy qr qr vr rv hqrprprhv Hqry qr pyhr ryhpvr yr qryprr Hqry qr hpr rr rvpv rhpvrqryprr Hqryqriprrqryp rr @h qrpvpvy rqr hyphhyhsqvqhqrrhrpr hvh Hqry qr pyhr t qr pyhr rrhyhprhwh Hqry qvivp qr h rhpvy vqvphqpyrqpr Hqryqrvvivyvqhq qrqrhpyhr uhpvh yh qri hq py yh vrh rqr hpprqr h yh rt qh Hqry qry vrshpr qr h pyhr hq qh vrqhqr rhpvrpq 8qvsvphpvy qr yh spvhyvqhq p pr vrshpr qr hv hyhpr rrpshrrprh v hh vyrrh ry vrh qv rphrr prviyr yh i vh Dsrqryhqvsrrpvhrphqh rr y Srvv qry Tvrh ry vrhsvhy
9rpvpvy
Cada resultado puede proporcionar informacin acerca de una o ms variables, que han de ser tenidas en cuenta para poder medir el futuro sistema. Las variables proporcionadas por cada resultado pueden verse tambin en 3URFHGLPLHQWR.
352&(',0,(172
El procedimiento general de Metis se divide en dos grandes etapas: GHILQLFLyQ y FRQVWUXFFLyQ. La etapa de definicin trata de definir el producto a construir, sentando las bases funcionales, estructurales y tecnolgicas del mismo. La etapa de construccin trata de llevar a cabo los planteamiento de la fase anterior, resultando en el producto finalizado. La etapa de definicin es esencialmente lineal, ya que, mientras no exista una base conceptual slida, cualquier decisin acerca de cualquier punto puede afectar drsticamente al resto del sistema, haciendo muy difcil el trabajo en paralelo. De todos modos, esto no debe considerarse un defecto de la metodologa, ya que los primeros pasos del desarrollo del producto constituyen un buen momento para el trabajo colectivo y la consolidacin del equipo. Por el contrario, la etapa de construccin es fundamentalmente distribuida, ya sea en el tiempo o en el espacio. Esta etapa consta de una serie de FLFORV GH GHVDUUROOR, todos iguales en su estructura funcional, que pueden ser acometidos uno detrs de otro por el mismo equipo de personas, o bien en paralelo por diferentes equipos. Habitualmente, las dependencias entre los conjuntos de caractersticas del sistema y la disponibilidad de recursos humanos, restringirn la intensidad del paralelismo que puede ser viable. A continuacin se muestra un esquema del procedimiento general de Metis. Obsrvese que, a menudo, una fase del procedimiento es dedicada ntegramente a una de las funciones anteriormente explicadas, y de este modo el mismo nombre hablaremos de fase o funcin indistintamente. Sin embargo, tambin existen funciones que no se desempean en ninguna fase concreta, si no a lo largo de todo el proceso, como es el caso del Control de Cambios.
7DEOD 5HVXOWDGRV HQ 0HWLV De modo similar al caso de las funciones, los resultados enumerados en la tabla anterior no han de producirse todos, ni en el orden en que aparecen. Su obtencin depender estrictamente de las funiones acometidas y del orden de las mismas. Puede verse qu resultados ha de generar cada funcin en 3URFHGLPLHQWR.
'
86Q6
8yqr8hiv 8srppvyqryh9prhpvyqrVhv 9vrx 6iyvv qr6yIvry 6vrpyvp qr6yIvry 8vpyqr 9rhyy!
Pirpvyqr Srvv
@qv Urpyytvp
Qyhvsvphpvy
8vpyqr 9rhyy

8vpyqr 9rhyyQ
Qrih Avhyr
9vrx 6iyvv qr7hwIvry 6vrpyvp qr7hwIvry
9vrx qr9rhyyr
9vrxqr Qrvrpvh
8qvsvphpvy
Tvpvhpvy
GHILQLFLyQ
FRQVWUXFFLyQ
WLHPSR
)LJXUD (VTXHPD GHO SURFHGLPLHQWR JHQHUDO GH 0HWLV (O WLHPSR IOX\H GH L]TXLHUGD D GHUHFKD Como se puede apreciar en la figura, la etapa de definicin es lineal, y se compone de etapas dedicadas a las siguientes funciones: Obtencin de Requisitos Anlisis de Alto Nivel Diseo Arquitectnico de Alto Nivel Estudio Tecnolgico Planificacin Diseo de Persistencia Codificacin Sincronizacin
Es importante resaltar que, as como la fase de obtencin de requisitos ha de ser llevada a cabo en toda su amplitud y profundidad, las fases de anlisis y diseo arquitectnico en esta etapa han de poseer un marcado carcter de abstraccin o alto nivel. No es necesario, ni deseable, profundizar durante esta etapa en todos y cada uno de los detalles del sistema, si no alcanzar un modelo del mismo amplio, completo y abstracto. Por otro lado, la etapa de construccin es la suma de una serie de FLFORV GH GHVDUUROOR concluidos por una fase de pruebas finales. Estos ciclos de desarrollo son iguales todos ellos en estructura, pero centrado cada uno en un FRQMXQWR GH FD UDFWHUtVWLFDV determinado. Un conjunto de caractersticas es una parte de la funcionalidad del sistema con alta interdependencia interna y al mismo tiempo relativamante independiente de otros segmentos de funcionalidad. Habitualmente, los conjuntos de caractersticas vienen dados por un servicio, un componente, o un grupo de operaciones de un componente. Cada ciclo de desarrollo se compone de las siguientes fases: Anlisis de Bajo Nivel Diseo Arquitectnico de Bajo Nivel Diseo de Detalle
Los ciclos de desarrollo de la etapa de construccin no han de disponerse necesariamente en una sucesin lineal en el tiempo, si no que pueden ser llevados a cabo por equipos diferentes total o parcialmente en paralelo. Tambin es importante resaltar que, as como las fases de anlisis y diseo arquitectnico en la anterior etapa de definicin posean un marcado carcter de abstraccin o alto nivel, estas mismas fases se reproducirn una y otra vez a lo largo de la etapa de construccin, con menor amplitud pero en toda su profundidad. Finalmente, existen algunas funciones que tienen lugar a lo largo de prcticamente todo el ciclo de vida del proyecto, como el Control de Cambios. Estas labores constituyen un soporte metodolgico a la buena marcha del proyecto, y suelen ser realizadas por equipos especficos. A continuacin se ofrece una descripcin detallada de cada una de las funciones de Metis. Para cada una se incluye, adems, una lista de los resultados que debe generar, as como una lista de las variables a las que da lugar.
2EWHQFLyQ GH 5HTXLVLWRV
2EMHWLYRV
Determinar qu necesitan los futuros usuarios del sistema que se desea construir, as como establecer criterios de validacin para dichos requisitos.
/RFDOL]DFLyQ HQ HO 3URFHGLPLHQWR
La obtencin de requisitos suele constitur la primera fase del procedimiento general, ya que no tiene sentido construir un sistema sin conocer bien las necesidades. Sin embargo, esta fase es prescindible en casos muy especiales en los que la necesidad sea perfectamente conocida, siendo entonces sustituible por la redaccin directa de los resultados necesarios (vase ms abajo). Adems, es posible realizar ciertas labores de obtencin de requisitos de forma sostenida a lo largo de todo el ciclo de vida del proyecto, que pueden dar lugar a porpuestas de cambio muy interesantes.
y la dificultad o complejidad tcnica que conlleva la realizacin de tal requisito. Al mismo tiempo, deben formalizarse las invariantes detectadas, que servirn para aclarar y reforzar la lista de requisitos del sistema. Una vez finalizado el documento de requisitos del sistema, los futuros usuarios deben revisarlo y aceptarlo. A partir de ese momento, los requisitos del sistema quedan cerrados, y cualquier cambio que se desee efectuar sobre ellos debe ser sometido a un proceso de control de cambios (vase &RQWURO GH &DPELRV).
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: 1HFHVLGDGHV La demanda inicial del usuario se pone por escrito antes de acometer la obtencin de requisitos, utilizando para ello un documento de WH[WR OLEUH. Los usuarios deben revisar y aceptar este resultado antes de que la definicin del sistema pueda proseguir. 'LFFLRQDULR GHO 6LVWHPD Todos los conceptos de inters para el sistema, sean de ndole estructural, funcional, restrictiva o tecnolgica, han de introducirse en un almacn centralizado y accesible, en forma de documento de WH[WR HVWUXFWXUDGR que incluya una descripcin exhaustiva para cada trmino. Es deseable que este almacn cuente con un soporte informtico especfico, ya que de este modo ser posible realizar bsquedas, elaborar listados y obtener informacin de modo rpido y sencillo. 5HTXLVLWRV GHO 6LVWHPD Las caractersticas que el sistema ha de poseer para ser considerado correcto integran este resultado, en forma de documento de WH[WR HV WUXFWXUDGR, que incluya para cada requisito un nombre, una descripcin, una lista de referencias al documento de Necesidades, y una cifra de prioridad.
&RQFHSWRV &ODYH
Los conceptos clave de esta funcin son LQYDULDQWH y UHTXLVLWR. Una invariante es una condicin que siempre ha de mantenerse en el sistema; por ejemplo, no puede existir ningn departamento sin director. Un requisito es una cualidad sencilla, autocontenida y verificable, que el sistema ha de poseer para ser considerado correcto. Es necesario hacer constar que todos los trminos, conceptos, ideas y relaciones utilizados a lo largo de esta fase han de ser perfectamente comprensibles tanto por los desarrolladores del sistema como por los futuros usuarios del mismo. Por lo tanto, es necesario evitar la introduccin de conceptos ajenos al dominio de aplicacin durante esta fase.
3URFHGLPLHQWR
El procedimiento a seguir comienza por plasmar por escrito la demanda inicial por parte de los futuros usuarios del sistema, es decir, las necesidades al respecto. Es importante resaltar que esta labor debe limitarse a poner por escrito los deseos de dichos usuarios, sean viables o no. De este modo, este documento servirn en el futuro como punto de comparacin para los requisitos del sistema y el informe de diferencias finales. Antes de continuar el proceso de desarrollo, este documento debe ser revisado y aceptado por los usuarios. Con las necesidades escritas, debe procederse a la definicin de los requisitos del sistema, tanto funcionales como restrictivos (a veces ambiguamente denominados no funcionales), a un alto nivel de abstraccin, tomando como punto de partida las mencionadas demandas de los futuros usuarios del sistema. Es necesario delimitar cada requisito como una entidad atmica, como un objetivo a perseguir. Despus, se debe asignar a cada requisito concreto una cifra de prioridad que refleje la probabilidad de que sea contemplado y satisfecho antes que los dems. Estas cifras de prioridad han de ser calculadas al menos en base a dos factores: la importancia que los futuros usuarios del sistema dan al requisito en cuestin,
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH 5HTXLVLWRV Se obtiene de los Requisitos del Sistema. 1~PHUR GH ,QWHUGHSHQGHQFLDV Se obtiene de los Requisitos del Sistema, contando cuntas dependencias entre requisitos aparecen.
&RQWURO GH &DPELRV
2EMHWLYRV
Asegurar que cualquier cambios realizado sobre los requisitos del sistema, una vez cerrados stos,
86Q6
no perjudica al desarrollo global del mismo. Sin este control, los cambios incocentemente introducidos en alguna parte del sistema podran repercutir negativamente en otros aspectos del mismo.
puesta de cambio se revisar de nuevo como si acabase de llegar. En cualquiera de los casos enumerados, la comisin debe redactar una justificacin para la decisin tomada, y hacrsela llegar al remitente de la propuesta de cambio tan pronto como sea posible.
El control de cambios debe realizarse contnuamente a partir del cierre de los requisitos del sistema (vase 2EWHQFLyQ GH 5HTXLVLWRV) y hasta la conclusin del ltimo ciclo de desarrollo.
5HVXOWDGRV
Esta funcin necesita de los siguientes resultados: 3URSXHVWD GH &DPELR Las propuestas de cambio se reciben en forma de documentos de WH[WR HVWUXFWXUDGR, incluyendo el nombre del remitente, su informacin de contacto (telfono, e-mail, etc.), la fecha y hora de redaccin, una descripcin exhaustiva del cambio propuesto, y una justificacin de la necesidad del mismo.
&RQFHSWRV &ODYH
Una SURSXHVWD GH FDPELR es una iniciativa para cambiar los requisitos del sistema una vez que han sido cerrados (vase 2EWHQFLyQ GH 5HTXLVLWRV), y en principio puede ser elaborada por cualquier futuro usuario del sistema, desarrollador del mismo, u otras personas involucradas. La FRPL VLyQ GH FRQWURO GH FDPELRV es un equipo de personas encargado de recibir las propuestas de cambio, reunirse peridicamente para revisar las propuestas existentes, examinar cada una, y decidir acerca de ellas. Esta comisin debe estar compuesta por desarrolladores, futuros usuarios del sistema, y otras partes implicadas en el desarrollo del mismo.
Al mismo tiempo, esta funcin puede modificar los siguientes resultados: 5HTXLVLWRV GHO 6LVWHPD Cualquier propuesta aceptada significa un cambio a los requisitos del sistema. Si se aaden nuevos requisitos, es necesario revisar las cifras de prioridad de los dems, por si fuese conveniente modificarlas.
3URFHGLPLHQWR
En cualquier momento, cualquier persona relacionada con el proyecto puede elaborar una propuesta de cambio y remitirla a la comisin de control de cambios. En cada reunin de esta comisin, deben revisarse todas las propuestas pendientes, evaluar los efectos globales que la realizacin del cambio propuesto supondra tanto para la marcha del desarrollo como para el sistema final, y decidir entre cuatro posibles opciones: $FHSWDU OD SURSXHVWD En este caso, el cambio propuesto se incorpora inmediatamente a los requisitos del sistema, se modifican los documentos pertinentes, y el cambio propuesto pasa a formar parte de dichos requisitos como cualquier otro. 5HFKD]DU OD SURSXHVWD $FHSWDU OD SURSXHVWD \ SRVSRQHU VX HMH FXFLyQ En este caso, el cambio queda definitivamente aceptado, pero no se incorpora a los requisitos del sistema, si no que se mantiene en un estado de espera hasta la fecha que la comisin estime oportuna. Llegada esta fecha, la comisin deber retomar la propuesta y decidir de nuevo entre incorporar el cambio a los requisitos del sistema, o bien posponer de nuevo su ejecucin. 3RVSRQHU OD GHFLVLyQ Si la comisin no cuenta con la informacin necesaria para tomar una decisin fundada, puede posponer la decisin para la fecha que estime conveniente. Llegada esta fecha, la pro-
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH 3URSXHVWDV GH &DPELR Se obtiene de las Propuestas de Cambio. 1~PHUR GH 3URSXHVWDV GH &DPELR $FHS WDGDV Se obtiene de las Propuestas de Cambio, una vez que se hayan procesado. 1~PHUR GH 3URSXHVWDV GH &DPELR 5H FKD]DGDV Se obtiene de las Propuestas de Cambio, una vez que se hayan procesado. 1~PHUR GH 3URSXHVWDV GH &DPELR $FHS WDGDV \ 3RVSXHVWDV Se obtiene de las Propuestas de Cambio, una vez que se hayan procesado. 1~PHUR GH 3URSXHVWDV GH &DPELR FRQ 'HFLVLyQ 3RVSXHVWD Se obtiene de las Propuestas de Cambio, una vez que se hayan procesado.
$QiOLVLV GH $OWR 1LYHO

2EMHWLYRV
Determinar la estructura del sistema a un alto nivel de abstraccin, as como definir los protocolos de interaccin entre las diferentes partes del mismo. Dado el carcter de alto nivel del anlisis en la etapa de definicin, es necesario evitar la profundizacin excesiva en partes especficas del sistema, siendo preferible un enfoque global e integrador.
Es importante resaltar que los futuros usuarios del sistema juegan un papel muy importante durante el anlisis de alto nivel, ya que han de participar en los trabajos correspondientes y validar los resultados obtenidos.
El anlisis de alto nivel suele constituir la segunda fase de la etapa de definicin, buscando con ella la confeccin de un modelo estructural y funcional del sistema en su globalidad, que pueda servir de infraestructura a elaboraciones posteriores. De todos modos, las labores posteriores de anlisis de bajo nivel podrn cambiar sustancialmente los resultados obtenidos durante esta fase.
&RQFHSWRV &ODYH
Un DFWRU es una entidad externa al sistema que se trata de construir, sea humano o no. Ejemplos de actores habituales son usuarios humanos, dispositivos como impresoras o sistemas de comunicaciones, u otros sistemas software. Un VHUYLFLR GHO VLVWHPD es una oferta realizada por el sistema en trminos de invocacin/respuesta, y que puede ser utilizado por un cliente externo, habitualmente un actor. Los servicios pueden llevar cualquier tipo y cantidad de informacin asociada a ellos. El conjunto de los servicios de un sistema forma el LQWHUIDFH GHO VLVWHPD. Finalmente, un FDVR GH XVR es, en esencia, un conjunto de interacciones entre el sistema y uno o ms actores, dirigido hacia la consecucin de un objetivo especfico. A menudo es posible modelar los casos de uso como secuencias de utilizacin de los servicios del sistema por parte de los actores.
sistema en estado Ready permite interaccin normal con el usuario, y puede ser estado de comienzo de un servicio. Un sistema en estado Modal permite una interaccin con el usuario muy restringida, normalmente a un elemento de interface de usuario determinado, y se siempre se da durante la ejecucin de un servicio, no pudiendo servir como comienzo de uno. Finalmente, un sistema en estado Busy no permite la interaccin con el usuario. Esto ltimo implica que las transiciones salientes de un estado Busy no pueden ser originadas por acciones de usuario. Es posible definir estados especficos derivados de cualquiera de estos tres estados genricos, as como definir nuevos estados no pertenecientes a ninguno de estos tres tipos. Cualquier estado Ready o Modal puede poseer parmetros, as como estar mapeado a uno o ms elementos de interface de usuario, que a su vez pueden poseer parmetros (vase ms abajo). Estos parmetros pueden ser utilizados en expresiones para ligar estados y en aserciones para validar el funcionamiento del servicio. Tambin es posible extraer comportamientos comunes de varios modelos de estados y construir con ellos estados compuestos genricos, que pueden ser despus referidos desde diferentes modelos de estados. Por otra parte, los bocetos de interface de usuario han de incluir un diseo adecuado de cada elemento de interface de usuario (ventanas, cuadros de dilogo, etc.), incluyendo adems los controles (o parmetros visibles al usuario) y parmetros no visibles que sean necesarios. Es necesario asociar elementos de interface de usuario a los estados definidos anteriormente, siendo posible en muchos casos asignar el mismo elemento de interface de usuario con diferentes valores para sus parmetros a distintos estados de ejecucin del mismo o diferentes servicios. Los controles y parmetros invisibles de cada elemento de interface de usuario sern accesibles desde los estados que utilicen dichos elementos de interface de usuario. Aunque el diseo del interface de usuario puede cambiar en fases futuras, es altamente deseable alcanzar cierta estabilidad durante esta fase de anlisis, ya que, de este modo, es posible establecer un estado de visual freeze sobre el sistema, el cual a su vez agiliza sustancialmente las labores de preparacin de la documentacin de usuario (vase &RQIHFFLyQ GH OD 'RFXPHQWDFLyQ GH 8VXDULR). Al mismo tiempo, y probablemente en paralelo, es necesario construir un modelo de clases del dominio, que contenga las clases, atributos, relaciones y roles correspondientes a lo expresado en los requisitos del sistema. Despus, y a partir de ste, se obtendr el modelo de clases del sistema eliminando las clases que representen actores externos al sistema, y dejando solamente
3URFHGLPLHQWR
El procedimiento a seguir comienza con la identificacin de los actores involucrados en el sistema, y con el modelado de casos de uso que describan todas las interacciones posibles entre ste y aquellos. Es posible encontrar descripciones de interacciones en los requisitos del sistema, o al menos, indicaciones acerca de qu eventos de entrada o salida pueden producirse. Es recomendable estructurar los casos de uso teniendo en cuenta los subconjuntos comunes que varios de ellos puedan presentar, as como posibles variaciones o extensiones. Despus se desarrollar el modelo de interface del sistema, extrayendo de cada caso de uso los servicios del sistema que los actores utilizan, modelando los pasos que la ejecucin de cada uno debe realizar, y diseando bocetos del interface de usuario durante la ejecucin de cada uno. Los pasos de la ejecucin de cada servicio deben modelarse en funcin de estados y transiciones, teniendo en cuenta que existen tres estados genricos predefinidos: Ready, Modal y Busy. Un
86Q6
aquellas que correspondan a conceptos que el sistema haya de manipular directamente. Tanto el modelo de interface del sistema como el modelo de clases han de expresarse en trminos del dominio de aplicacin, comprensibles por los futuros usuarios del sistema, y tratando de evitar la introduccin de conceptos ajenos a dicho dominio. Los usuario, de hecho, deben participar en el modelado de informacin conducente a los citados modelos, as como validar los resultados obtenidos. Es necesario tener en cuenta que el proceso de anlisis rara vez es lineal, si no que tiene lugar a lo largo de sucesivos ciclos de refinado y revisin de lo ya hecho. De este modo, no es adecuado tratar de construir los modelos de clases y el interface del sistema de una vez, si no que es mucho ms apropiado realizar una primera aproximacin, refinarla, e iterar de nuevo desde el principio.
1~PHUR GH (OHPHQWRV GH ,QWHUIDFH GH 8VXDULR GHO 6LVWHPD Se obtiene del Modelo de Interface del Sistema.
'LVHxR $UTXLWHFWyQLFR GH $OWR 1LYHO

2EMHWLYRV
Disponer los conceptos integrantes del sistema a construir en un marco estructural adecuado para su implementacin. En concreto, se centra en la delimitacin de componentes del sistema, que interactuarn entre s para formar el sistema en su conjunto.
El diseo arquitectnico de alto nivel suele constituir la tercera fase de la etapa de definicin, buscando con ella la confeccin de un modelo estructural del sistema que pueda servir de infraestructura a elaboraciones posteriores. De modo similar al caso del anlisis de alto nivel, las labores posteriores de diseo arquitectnico de bajo nivel podrn cambiar sustancialmente los resultados obtenidos durante esta fase.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: &DVRV GH 8VR Las interacciones entre los actores y el sistema han de formalizarse como casos de uso mediante GLDJUDPDV GH HYHQWRV, que muestran los eventos de entrada y salida del sistema. 0RGHOR GH &ODVHV GHO 'RPLQLR Debe expresarse mediante GLDJUDPDV GH FODVHV, que contengan todas las clases, relaciones y roles del dominio de aplicacin. 0RGHOR GH &ODVHV GHO 6LVWHPD Es un subconjunto del anterior, y debe expresarse tambin mediante GLDJUDPDV GH FODVHV, pero eliminando las clases, relaciones y roles que el sistema no necesite manipular directamente. 0RGHOR GH ,QWHUIDFH GHO 6LVWHPD Describe el interface del sistema, utilizando GLD JUDPDV GH HVWDGRV GH VHUYLFLRV para mostrar la progresin de la ejecucin de cada servicio, y ERFHWRV GH HOHPHQWRV GH LQWHUIDFH GH XVXDULR para mostrar el aspecto del interface de usuario del futuro sistema.
&RQFHSWRV &ODYH
Un FRPSRQHQWH es una parte del sistema con una fuerte cohesin interna, capaz de encapsular informacin y comportamiento y ocultarlos a otros componentes. Los diferentes componentes del sistema pueden comunicarse mediante la ejecucin de RSHUDFLRQHV. El conjunto de operaciones de cada componente constituye su LQWHUIDFH. El modo genrico en que varios componentes se comunican entre s da lugar a un HVWLOR DUTXLWHF WyQLFR; por ejemplo, es habitual encontrar sistemas compuestos por varios componentes que se comunican cada uno con otros dos, excepto dos de ellos, que se comunican con solamente uno. Esta estructura es denominada en capas, y de hecho constituye uno de los estilos arquitectnicos ms habituales. Podemos entender los estilos arquitectnicos como patrones de diseo de muy alto nivel, ya que se aplican a la estructura de un sistema completo en vez de a problemas especficos. Un SURFHVR es una secuencia de instrucciones que se ejecuta en una mquina, es decir, se utiliza el trmino en su acepcin convencional.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH &ODVHV GHO 6LVWHPD Se obtiene del Modelo de Clases del Sistema. 1~PHUR GH 5HODFLRQHV GHO 6LVWHPD Se obtiene del Modelo de Clases del Sistema, usndose los equivalentes binarios de las relaciones (vase *ORVDULR) 1~PHUR GH 6HUYLFLRV Se obtiene del Modelo de Interface del Sistema.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza con la eleccin de un estilo arquitectnico adecuado para el sistema que se trata de construir, a partir de la informacin aportada por el modelo de clases del sistema y el interface del mismo. Existen catlogos de estilos arquitectnicos que los desarrolladores pueden utilizar para localizar
"
un estilo adecuado o generar un estilo combinado a partir de dos o ms estilos preexistentes. A continuacin, y tomando como base la informacin mencionada, es necesario esbozar componentes e interacciones entre ellos. Grandes grupos de clases o de servicios pueden sugerir componentes. Tambin es necesario establecer qu componentes o grupos de componentes conformarn procesos diferentes. Esta estructura debe ser plasmada en un modelo de arquitectura del sistema. Es necesario resaltar que cualquier componente es susceptible de ser descompuesto, a su vez, en sub-componentes, y stos en sub-subcomponentes, hasta el nivel de detalle que sea necesario. De todos modos, no es habitual sobrepasar una profundidad de tres niveles, obedeciendo tpicamente el primero a la distribucin fsica del sistema, segn procesos o libreras independientes, y los siguientes a particiones estructurales de cada uno de stos.
llevar a la prctica diseos tericos en un dominio de aplicacin especfico.
3URFHGLPLHQWR
El estudio tecnolgico de un sistema constituye un proceso difcilmente tipificable, ya que depende en gran medida de factores ajenos a la metodologa en uso, como la oferta del mercado y la capacidad adquisitiva del equipo de desarrollo y de los futuros usuarios del sistema. De todos modos, habitualmente es posible extraer FRQGLFLR QHV que las tecnologas a usar deben cumplir a partir de los requisitos del sistema, y principalmente de los requisitos restrictivos o no funcionales. En cualquier caso, es necesario tomar decisiones con previsin de futuro, ya que el cambio tecnolgico puede ser ms rpido que el propio ciclo de vida del proyecto. Adems, es deseable plantear alternativas secundarias a las tecnologas elegidas, as como vas de migracin para preparar el terreno para posibles cambios poco deseables.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: 0RGHOR GH $UTXLWHFWXUD GHO 6LVWHPD Este modelo describe la estructura del sistema en cuanto a su distribucin lgica y conceptual en componentes. Deben usarse GLDJUDPDV GH FRPSRQHQWHV para mostrar dicha estructura.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: /LVWD GH 5HFXUVRV 7HFQROyJLFRV Consiste en una lista de las tecnologas a utilizar, mostrada mediante WH[WR HVWUXFWXUDGR. Para cada tecnologa debe incluirse una descripcin breve pero completa, as como informacin relativa a la disponibilidad temporal (cundo se puede conseguir, y hasta cundo estar disponible) y econmica (cul es el coste) de la misma, su curva de aprendizaje o grado de dificultad de incorporacin, y alternativas secundarias.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH &RPSRQHQWHV Se obtiene del Modelo de Arquitectura del Sistema.
(VWXGLR 7HFQROyJLFR
2EMHWLYRV
Elegir las tecnologas a utilizar en la implementacin del futuro sistema, incluyendo plataformas hardware y software, infraestructuras de comunicaciones, lenguajes de programacin, sistemas de gestin de bases de datos, herramientas de desarrollo, etc.
9DULDEOHV
Los resultados de esta funcin no proporcionan variables.
3ODQLILFDFLyQ
2EMHWLYRV
Distribuir la funcionalidad del futuro sistema en conjuntos de caractersticas, incluyendo para cada uno su prioridad, las dependencias con los dems, y sus correspondencias con los requisitos del sistema.
Este estudio tiene lugar habitualmente como fase previa a la planificacin general al final de la etapa de definicin, ya que normalmente es muy conveniente disponer de informacin concreta respecto a las tecnologas a emplear durante la construccin del sistema.
Esta funcin es imprescindible como cierre de la etapa de definicin del sistema, ya que establece el calendario de trabajo para la etapa de construccin. Adems, cada fase de sincronizacin de los subsiguientes ciclos de desarrollo conlleva una
&RQFHSWRV &ODYH
Una WHFQRORJtD es un segmento concreto de conocimiento, disponible comercialmente, a menudo en forma de productos o servicios, que permite
86Q6
revisin de los resultados obtenidos en esta fase de planificacin.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: &RQMXQWRV GH &DUDFWHUtVWLFDV Cada conjunto debe documentarse mediante WH[WR HVWUXFWXUDGR, incluyendo su descripcin, su cifra de prioridad, los requisitos del sistema que pretende satisfacer, los conjuntos que necesita, los conjuntos que lo necesitan, y la combinacin de elementos especficos que lo constituyen (servicios, componentes completos, operaciones, etc.). 3ODQ *HQHUDO GH 7UDEDMR Describe la planificacin general de los ciclos de desarrollo a acometer mediante WH[WR HVWUXFWX UDGR. Para cada ciclo ha de incluirse una referencia al conjunto de caractersticas que trata de implementar, las fechas estimadas de comienzo y final, y los recursos necesarios, tanto humanos como materiales.
&RQFHSWRV &ODYH
Un FRQMXQWR GH FDUDFWHUtVWLFDV es una parte de la funcionalidad del sistema con alta interdependencia interna y relativamante independiente de otros segmentos de funcionalidad. Un FLFOR GH GH VDUUROOR es una unidad de trabajo cuyo objetivo es implementar un conjunto de caractersticas determinado. Utilizando estos conceptos, es posible definir XPEUDOHV GH DOFDQFH sucesivos; por ejemplo, podra establecerse que cierta funcionalidad es absolutamente imprescindible, otro conjunto de caractersticas muy conveniente, y un ltimo conjunto, deseable. De este modo, el desarrollo del sistema puede comenzar dirigido hacia el primer umbral, pero sin dejar de perseguir los siguientes.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza con la definicin de los conjuntos de caractersticas del sistema. Es necesario definir los conjuntos necesarios como para que toda la funcionalidad del sistema quede cubierta, y teniendo en cuenta que el grado de dificultad y complejidad de unos y otros no debe ser enormemente distinto, ya que servirn como unidad de organizacin del futuro plan de trabajo. Los conjuntos de caractersticas demasiado amplios o complejos deben ser divididos en conjuntos de caractersticas ms abordables. Tpicamente, los conjuntos de caractersticas vienen dados por un servicio, un componente, u operaciones concretas de un componente. A continuacin se relacionar cada conjunto de caractersticas con los requisitos que persigue satisfacer, y se describirn las interdependencias de unos conjuntos de caractersticas respecto a otros. Despus se asignar una cifra de prioridad a cada conjunto, teniendo en cuenta las prioridades reflejadas en la lista de requisitos del sistema. Finalmente, se elaborar un plan de trabajo, ordenando los diferentes conjuntos de caractersticas segn su prioridad y sus interdependencias, estableciendo los recursos necesarios y tiempos estimados para cada uno, y estableciendo diferentes umbrales de alcance del sistema. Esta ordenacin no tiene por qu ser lineal, si no que pueden utilizarse mecanismos de desarrollo paralelo siempre que las dependencias entre conjuntos as lo permitan. Tngase en cuenta que el plan de trabajo mencionado es solamente una intencin, y que la propia filosofa subyacente a un ciclo de vida evolutivo implica que la modificacin de tal plan una vez comenzada su ejecucin ha de ser tomada como cosa normal e incluso deseable.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH &RQMXQWRV GH &DUDFWHUtVWLFDV Se obtiene de los Conjuntos de Caractersticas. 1~PHUR GH 'tDV3HUVRQD GH 7UDEDMR para cada ciclo de desarrollo. Se obtiene del Plan General de Trabajo.
&RQIHFFLyQ GH OD 'RFXPHQWDFLyQ GH 8VXDULR

2EMHWLYRV
Redactar y formatear la documentacin de usuario, que depender en forma y contenido del tipo de sistema en construccin, as como de la audiencia pretendida.
Dada la dependencia que la documentacin de usuario posee respecto al interface de usuario del sistema, es deseable que ste se encuentre lo ms estabilizado posible antes de preparar dicha documentacin. Por esta razn, es recomendable comenzar esta funcin tras el anlisis de alto nivel (ya que ste determina en gran medida el interface de usuario del sistema), y prolongarla tanto como sea necesario en paralelo a los ciclos de desarrollo.
&RQFHSWRV &ODYH
Esta funcin no introduce nuevos conceptos.
3URFHGLPLHQWR
El modelo de interface del sistema es un buen punto de partida para describir los servicios que ste puede prestar a los usuarios finales. Es conveniente enfocar la descripcin del sistema desde un punto de vista funcional, al menos en una primera fase, dado que los usuarios suelen trabajar mejor a este nivel. De todos modos, no es adecuado omitir una descripcin estructural, y los modelos de clases del dominio y del sistema son fuentes de informacin apropiadas para esto.
3URFHGLPLHQWR
El procedimiento a seguir comienza con la profundizacin en los modelos de clases y de interface del sistema, haciendo especial hincapi en la determinacin de atributos y en la especificacin de la direccionalidad de las relaciones en cuanto a su navegacin. Como punto de partida puede utilizarse la informacin de alto nivel que acerca del conjunto de caractersticas actual se haya obtenido en la fase de anlisis de alto nivel de la etapa de definicin. A menudo ser necesario consultar casos de uso concretos o los requisitos del sistema involucrados en el conjunto de caractersticas a desarrollar. De este modo se construirn los modelos de clases y de interface de los componentes involucrados en el conjunto de caractersticas actual. Ntese que, en el muy probable caso de que dicho conjunto de caractersticas no cubra un componente en su totalidad, los modelos obtenidos describirn al mismo solo parcialmente, y su especificacin completa solamente emerger tras varios ciclos de desarrollo. Esta situacin no debe constituir un problema si el anlisis y el diseo arquitectnico de alto nivel han sido adecuados; de todos modos, es recomendable minimizar estas situaciones obteniendo componentes pequeos o medianos que cuya implementacin quede repartida, a lo sumo, en uno o dos conjuntos de caractersticas. De nuevo, es necesario tener en cuenta que el proceso de anlisis rara vez es lineal, si no que debe enfocarse como un proceso que tiene lugar a lo largo de sucesivos ciclos de refinado y revisin.
5HVXOWDGRV
Esta funcin puede dar lugar a los siguientes resultados: 0DQXDO GHO 8VXDULR Se trata de un documento orientado a la formacin del usuario final, y debe contener una descripcin del sistema eminentemente funcional, aunque puede incluir tambin una descripcin estructural posterior. Debe expresarse mediante WH[WR OLEUH. *XtD GH 5HIHUHQFLD 7pFQLFD Se trata de un documento orientado a la consulta directa por parte del usuario final, y debe ofrecer una descripcin del sistema altamente estructural. Debe expresarse mediante WH[WR HVWUXFWXUDGR.
9DULDEOHV
$QiOLVLV GH %DMR 1LYHO

2EMHWLYRV
Elaborar un modelo especfico del componente a construir, o de una parte del mismo si el ciclo de desarrollo actual no lo cubre por completo.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: 0RGHOR GH &ODVHV GHO &RPSRQHQWH Constituye una versin especfica y ms profunda del modelo de clases del sistema, centrada en cada componente del conjunto de caractersticas actual. Debe expresarse tambin mediante GLDJUDPDV GH FODVHV. 0RGHOR GH ,QWHUIDFH GHO &RPSRQHQWH Describe el interface de cada componente, utilizando GLDJUDPDV GH HVWDGRV GH VHUYL FLRV para mostrar la progresin de la ejecucin de cada servicio, y ERFHWRV GH HOH PHQWRV GH LQWHUIDFH GH XVXDULR para mostrar el aspecto del interface de usuario.
Esta funcin aparece tpicamente como primer paso de cada ciclo de desarrollo, elaborando sobre los resultados de la etapa de definicin y de ciclos de desarrollo anteriores.
&RQFHSWRV &ODYH
Un VHUYLFLR GH FRPSRQHQWH es una oferta realizada por un componente en trminos de invocacin/respuesta, y que puede ser utilizado por un cliente externo, habitualmente otro componente. De modo similar al caso de los servicios del sistema, los servicios de componente pueden llevar cualquier tipo y cantidad de informacin asociada a ellos. El conjunto de los servicios de un componente forma el LQWHUIDFH GHO FRPSRQHQWH.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH &ODVHV GHO &RPSRQHQWH Se obtiene del Modelo de Clases del Componente.
86Q6
1~PHUR GH 5HODFLRQHV GHO &RPSRQHQWH Se obtiene del Modelo de Clases del Componente, usndose los equivalentes binarios de las relaciones (vase *ORVDULR) 1~PHUR GH 2SHUDFLRQHV GHO &RPSRQHQ WH Se obtiene del Modelo de Interface del Componente. 1~PHUR GH (OHPHQWRV GH ,QWHUIDFH GH 8VXDULR GHO &RPSRQHQWH Se obtiene del Modelo de Interface del Componente.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: 0RGHOR GH $UTXLWHFWXUD GHO &RPSRQHQ WH Este modelo describe la estructura de cada componente en cuanto a su distribucin lgica y conceptual en subcomponentes. Deben usarse GLDJUDPDV GH FRPSRQHQWHV para mostrar dicha estructura.
'LVHxR $UTXLWHFWyQLFR GH %DMR 1LYHO

2EMHWLYRV
Disponer los conceptos integrantes de cada componente a construir en un marco estructural adecuado.
9DULDEOHV
Los resultados de esta funcin pueden alterar las siguientes variables: 1~PHUR GH &RPSRQHQWHV Se ajusta segn el Modelo de Arquitectura del Componente.
'LVHxR GH 'HWDOOH
2EMHWLYRV
Elaborar un modelo concreto de cada operacin capaz de ser implementado a nivel de mquina.
Continuando el paralelismo con la etapa de definicin, esta funcin aparece tpicamente tras el anlisis de bajo nivel, como segunda fase de cada ciclo de desarrollo.
Esta funcin debe acometerse justo despus del diseo arquitectnico de bajo nivel, en cada ciclo de desarrollo, ya que especifica el modo de implementar cada una de las operaciones involucradas.
&RQFHSWRV &ODYH
La estructura de un componente puede organizarse en torno a SDWURQHV GH GLVHxR, o soluciones genricas aplicables a un problema especfico mediante un proceso de instanciacin.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza con la eleccin de patrones de diseo adecuados para el conjunto de caractersticas que se trata de desarrollar, a partir de la informacin aportada por los modelos de clases y de interface de cada componente involucrado. De igual manera que en el caso de los estilos arquitectnicos, existen catlogos de patrones de diseo (vase Gamma HW DO 1995) que los desarrolladores pueden utilizar para localizar un estructuras adecuadas o generar combinaciones a partir de dos o ms patrones existentes. A continuacin, y tomando como base la informacin mencionada, puede ser necesario esbozar sub-componentes e interacciones entre ellos. Algunos grupos de clases o de operaciones del sistema pueden sugerir sub-componentes. Esta estructura debe ser utilizada para refinar el modelo de arquitectura del sistema, y confeccionar de este modo un modelo de arquitectura del componente. Estas labores sern menos necesarias cuanto ms detallado haya sido el modelo de arquitectura del sistema obtenido durante si la fase de diseo arquitectnico de alto nivel. En cualquier caso, solamente los sistemas medianos o grandes mostrarn la necesidad de elaborar estructuras jerrquicas de componentes y sub-componentes.
&RQFHSWRV &ODYH
El objeto (o clase) que inicia una operacin se denomina GLVSDUDGRU, y el que responde directamente a una operacin se denomina FRQWURODGRU. El resto de los objetos (o clases) que participan en la consecucin de los objetivos de dicha operacin, se denominan FRODERUDGRUHV. El conjunto de operaciones de una misma clase controladora, junto con los atributos de la misma y la implementacin de sus relaciones, constituye el LQWHUID FH de dicha clase. Por otra parte, la YLVLELOLGDG entre dos clases define el modo en que los objetos de la primera pueden acceder a los objetos de la segunda mediante referencias que puedan poseer, y la semntica de dicho acceso. En concreto, esta semntica puede variar segn cuatro dimensiones diferentes: WLHPSR GH YLGD (referencia dinmica o bien permanente), FRQFXUUHQFLD (referencia exclusiva o bien compartida), OLJD]yQ (referencia ligada o no ligada) y PXWDELOLGDG (referencia constante o variable).
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza completando el modelo de clases de cada componente involucrado, ya que a menudo es necesario introducir clases que poco tienen que ver
&
con el dominio de aplicacin de sistema en construccin, pero que son no obstante necesarias para la implementacin del mismo. A continuacin debe elegirse la clase controladora de cada operacin, y construirse un modelo dinmico que muestre las colaboraciones entre objetos que han de darse para implementar dicha operacin. Tambin es necesario considerar, para cada operacin, si sta se realiza de forma sncrona o bien asncrona, y tener adems en cuenta temas como la capacidad PXOWLWKUHDG del sistema o la concurrencia en el uso de recursos. Adems, y utilizando los modelos dinmicos de operaciones, se definirn las visibilidades entre clases, haciendo especial hincapi en distinguir si cada visibilidad efectiva puede concretarse como una agregacin fsica, es decir, como la contencin de una clase dentro de otra. Finalmente debe construirse o ampliarse el modelo de interface de cada clase involucrada, aadiendo al mismo las operaciones modeladas y la implementacin de las relaciones utilizadas para conseguir las visbilidades establecidas.
resultados a obtener se hallan estrechamente relacionadas con el mencionado diseo de detalle.
&RQFHSWRV &ODYH
Una FODVH DWULEXWR o UHODFLyQ SHUVLVWHQWH es aqulla que puede ser guardada en un almacn persistente y recuperada ms tarde. Normalmante, la informacin persistente se almacena y recupera en grupos de clases estrechamente relacionados, denominados JUXSRV GH SHUVLVWHQFLD. Por otra parte, la persistencia de un grupo puede ser FXDOLILFD GD, si es posible manipular los objetos persistentes individualmente, mediante algn LGHQWLILFDGRU GH SHUVLVWHQFLD, o bien QR FXDOLILFDGD, si todos los objetos persistentes del grupo han de ser tratados en bloque. Existen cinco operaciones especiales relacionadas con los mecanismos de persistencia: create, load, save, release y destroy. La RSHUDFLyQ FUHDWH es similar a new, pero crea un nuevo objeto persistente y lo guarda. La RSHUD FLyQ ORDG crea un objeto persistente a partir de informacin almacenada previamente, y solo aparece en grupos con persistencia cualificada. La RSHUDFLyQ VDYH guarda un objeto persistente, sincronizando as su estado con la informacin almacenada. La RSHUDFLyQ UHOHDVH libera un objeto persistente, eliminando el objeto de modo similar a delete, pero sin borrar la informacin asociada del almacn persistente. Solo aparece en grupos con persistencia cualificada. Finalmente, la RSHUDFLyQ GHVWUR\ elimina un objeto persistente y borra la informacin asociada.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: 0RGHOR 'LQiPLFR GH OD 2SHUDFLyQ Describe cmo se produce cada operacin concreta, expresado como GLDJUDPDV GH FRODERUDFLyQ y VHXGRFyGLJR. 0RGHOR GH 9LVLELOLGDG Describe la visibilidad de cada clase, expresado mediante GLDJUDPDV GH YLVLELOLGDG. 0RGHOR GH ,QWHUIDFH GH OD &ODVH Describe el interface de una clase, expresado mediante VHXGRFyGLJR.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza por la identificacin de las clases y relaciones que han de ser persistentes. Adems, dentro de cada clase, es necesario establecer si todos los atributos sern persistentes o solamente lo sern algunos de ellos. A continuacin deben definirse los grupos de persistencia a partir de clases estrechamente relacionadas, y decidir, para cada grupo, si la persistencia ser cualificada o no cualificada. En el primer caso, ser necesario tambin establecer el identificador de persistencia (habitualmente, un atributo de una clase del grupo) del grupo. Una vez realizado esto, ser necesario decidir qu clase ser responsable de gestionar la persistencia de cada grupo. Esta clase podr pertenecer a dicho grupo, o bien ser externa al mismo. A veces es incluso adecuado definir una clase especial cuyo propsito sea actuar como responsable de persistencia de todos los grupos de persistencia del sistema. Finalmente, es necesario incorporar las operaciones especiales de persistencia al modelo de interface de la clase responsable de persistencia de cada grupo.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH $WULEXWRV GH OD &ODVH Se obtiene del Modelo de Interface de la Clase. 1~PHUR GH 2SHUDFLRQHV GH OD &ODVH Se obtiene del Modelo de Interface de la Clase.
'LVHxR GH 3HUVLVWHQFLD
2EMHWLYRV
Establecer los mecanismos por los cuales alguna de la informacin manejada por el sistema podr ser guardada y recuperada en almacenes persistentes.
Esta funcin debe acometerse despus del diseo de detalle, en cada ciclo de desarrollo, ya que la modularizacin del sistema debe estar clara, y los
'
86Q6
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: 0RGHOR GH 3HUVLVWHQFLD Describe los mecanismos de persistencia elegidos, expresados como WH[WR HVWUXFWXUDGR, incluyendo para cada grupo de persistencia su nombre y descripcin, si el modo de persistencia elegido es cualificado o no cualificado, el identificador de persistencia en su caso, y la clase responsable de persistencia.
diccionario del sistema y de los modelos de interfaces de clases a los lenguajes o sistemas de descripcin elegidos. Finalmente, se completar este esqueleto con la lgica de decisiones y los algoritmos embebidos en cada operacin de cada clase.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: &yGLJR )XHQWH Constituye la implementacin final del sistema, en forma de FyGL JR IXHQWH.
Adems, esta funcin puede modificar los siguientes resultados: 0RGHOR 'LQiPLFR GH OD 2SHUDFLyQ Se incorporarn los modelos de las operaciones especiales de persistencia. 0RGHOR GH 9LVLELOLGDG Es posible que se altere la visibilidad entre las clases de cada grupo de persistencia y su clase responsable de persistencia. 0RGHOR GH ,QWHUIDFH GH OD &ODVH Se incorporarn las operaciones especiales de persistencia.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH /tQHDV GH &yGLJR )XHQWH GH OD &ODVH Se obtiene del Cdigo Fuente.
6LQFURQL]DFLyQ
2EMHWLYRV
Comprobar que la funcionalidad aadida al sistema durante el ciclo de desarrollo actual es adecuada, e introducir en el proceso de desarrollo las variaciones necesarias.
9DULDEOHV
Es necesario realizar una sincronizacin como final de cada ciclo de desarrollo.
&RGLILFDFLyQ
2EMHWLYRV
Traducir a cdigo fuente el modelo dinmico de cada operacin a implementar.
&RQFHSWRV &ODYH
Esta funcin finaliza el proceso de implementacin de una operacin, por lo cual debe aparecer tras la fase de diseo de detalle en cada ciclo de desarrollo.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza dejando que los futuros usuarios del sistema utilicen el sistema parcialmente construido hasta el momento, indicndoles que deben ejercitar principalmente la funcionalidad aadida en el ciclo de desarrollo actual. Al mismo tiempo, es necesario recoger la informacin que dichos usuarios puedan proporcionar acerca de su experiencia utilizando el sistema. Los aspectos en los que es conveniente centrarse son, sobre todo, aquellos relativos a la comparacin entre la funcionalidad exhibida por el sistema y la planificada en la lista de requisitos desarrollada durante la etapa de definicin. Finalmente, es necesario introducir esta informacin en el proceso de desarrollo y revisar el plan general de trabajo a la luz de la nueva informacin, para aadir nuevos ciclos de desarrollo, modificar el orden y/o el contenido de los planificados, o incluso eliminar algunos si fuese necesario.
&RQFHSWRV &ODYH
Es importante resaltar que el trmino FyGLJR IXHQWH no solo se refiere a texto de un programa, si no que tambin incluye definiciones de esqemas de bases de datos, descripciones de elementos del interface de usuario, etc.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase comienza completando los modelos de interface de las clases involucradas, principalmente incorporando atributos a partir del modelo de clases del componente en cuestin. Simultneamente, y a partir del diccionario del sistema, se deben codificar las definiciones y estructuras de datos que de l surjan directamente. A continuacin se codificar un esqueleto de cdigo fuente traduciendo la informacin del
5HVXOWDGRV
Esta funcin puede modificar sustancialmente los siguientes resultados: &RQMXQWRV GH &DUDFWHUtVWLFDV Es posible que se aadan, modifiquen (en cualquier sentido) o eliminen conjuntos de caractersticas si la marcha del proyecto as lo demanda. 3ODQ *HQHUDO GH 7UDEDMR Es posible que se altere la secuencia de ciclos de desarrollo, o incluso que se aadan nuevos ciclos o se modifiquen o eliminen algunos ciclos existentes.
3URFHGLPLHQWR
El procedimiento a seguir en esta fase es sencillo; se probar el sistema en todos sus aspectos, contrastando la funcionalidad del mismo con los requisitos iniciales de los usuarios y utilizando la demanda inicial presentada por los mismos. Finalmente, se evaluarn las diferencias encontradas, tratando de encontrar explicaciones a ellas, y sugiriendo alternativas potenciales que las hubiesen evitado.
5HVXOWDGRV
Esta funcin da lugar a los siguientes resultados: ,QIRUPH GH 'LIHUHQFLDV )LQDOHV Debe expresar las diferencias entre los requisitos del sistema y el producto obtenido mediante WH[WR OLEUH.
9DULDEOHV
Los resultados de esta funcin pueden alterar las siguientes variables: 1~PHUR GH &RQMXQWRV GH &DUDFWHUtVWLFDV Se ajusta segn los Conjuntos de Caractersticas. 1~PHUR GH 'tDV3HUVRQD GH 7UDEDMR para cada ciclo de desarrollo. Se ajusta segn el Plan General de Trabajo.
9DULDEOHV
Los resultados de esta funcin proporcionan las siguientes variables: 1~PHUR GH 'LIHUHQFLDV )LQDOHV Se obtiene del Informe de Diferencias Finales.
3UXHEDV )LQDOHV
2EMHWLYRV
Esta funcin tiene por objetivo contrastar el producto finalmente obtenido con los requisitos inicialmente planteados por los usuarios del mismo. Es necesario resaltar que esta contrastacin ha de ser enfocada como un proceso meramente evaluativo y nunca correctivo, ya que las correcciones debidas a posibles desviaciones de los requisitos o a la aparicin de requisitos nuevos a lo largo del proceso de desarrollo debern haber sido detectadas durante los diferentes ciclos de desarrollo e introducidas de forma inmediata. Pretender corregir un sistema que no responda a sus requisitos en este punto traiciona la filosofa de los ciclos de vida evolutivos, y convierte en intiles los esfuerzos realizados al hacer que los usuarios del sistema evalen el mismo en numerosas ocasiones a lo largo de su construccin. De este modo, esta fase debe probar el sistema para evaluar las diferencias entre lo esperado y lo conseguido, que idealmente han de tender a cero, y analizar esta informacin cara a proyectos futuros.
127$&,1
7H[WR /LEUH
Texto escrito libre, sin restricciones de estructura o volumen.
7H[WR (VWUXFWXUDGR
Texto escrito estructurado en epgrafes o secciones predefinidas.
'LDJUDPDV GH (YHQWRV
Un diagrama de eventos muestra una secuencia temporal de interacciones puntuales entre un sistema y uno o ms actores. Cada interaccin puntual es modelada como un evento, que puede ser de entrada si parte de un actor y es recibido por el sistema, o de salida si nace en el sistema y se dirige a un actor. La Figura 2 muestra un ejemplo de diagrama de eventos. Las partes implicadas (sistema y actores) son representadas mediante lneas verticales paralelas, y se considera que el tiempo fluye de arriba hacia abajo. Los eventos se denotan como flechas horizontales (son sucesos instantneos) entre las partes correspondientes, y han de rotularse con un nombre indicativo y una lista de la informacin asociada, si existe. Los nombre de los eventos se disponen sobre la flecha correspondiente a cada uno, mientras que las listas de informacin asociada se colocan
Esta funcin debe acometerse al final de la etapa de construccin, fuera ya de todo ciclo de desarrollo.
&RQFHSWRV &ODYH
!
86Q6
debajo. Una flecha comenzando con un crculo denota la iniciativa de la conversacin. Un rectngulo blanco superpuesto a la lnea de una parte representa una espera. Una lnea horizontal corta a travs de una lnea vertical representa el final de la conversacin, si es contnua, o bien un final condicional si es de puntos. En este caso, una nota al pie debe recoger la condicin de finalizacin. Un cuadrado oscuro sobre una lnea de
involucradas. El nombre de la asociacin figura dentro de rombo, y debe interpretarse en la direccin sealada por una flecha colocada cerca de dicho rombo. La cardinalidad de cada clase figura junto al recuadro de cada una, junto a la lnea que la une con el rombo. El rol que una clase juega en una relacin, si alguno, se hace figurar tambin junto a dicha lnea, entre corchetes. Las agregaciones son mostradas mediante un peque-
Actor 1
Comienzo (a, b, c) Salida 1
Sistema
Actor 2
1. Final si a = 0.
(1)
2. Validar id. Final si no es vlido.
1..3
Entrada 1 (id) (2) Salida 2 (informacin asociada) Salida 3
SubCaso 1 Entrada 2
)LJXUD 'LDJUDPD GH HYHQWRV una parte representa un proceso que dicha parte ha de realizar. Una nota al pie debe describir dicho proceso. Un recuadro de puntos que encierra a una secuencia de eventos y procesos indica que dicha secuencia puede repetirse tantas veces como se indique. Un recuadro de lnea contnua cubriendo las lneas de todas las partes implicadas indica el subcaso cuyo nombre figura dentro de dicho rectngulo; un subcaso es, en efecto, un caso de uso que debe hallarse documentado mediante su propio diagrama de eventos, y que se produce en el seno del que se describe. o rombo sin rotular pegado a la clase compuesta, y unido a la clase componente mediante una lna. Las cardinalidades y roles se muestran de igual manera. La navegabilidad de cada asociacin o agregacin se denota mediante una pequea flecha apuntando desde la clase origen hacia la relacin.
'LDJUDPDV GH &ODVHV
Un diagrama de clases muestra la estructura de un sistema, o de una parte de un sistema, mediante las clases, atributos, roles y relaciones involucrados. La Figura 3 muestra un ejemplo de diagrama de clases. Las clases son representadas mediante recuadros divididos en dos secciones mediante una lnea horizontal. La seccin superior lleva el nombre de la clase, mientras que la seccin inferior porta la lista de atributos. Las relaciones entre clases se muestran de modos diferentes segn el tipo de relacin. Las asociaciones son representadas mediante rombos conectados a las clases
Banco
Nombre
!
Cliente
Cuenta
1..n Cdigo Saldo 1..n
posee
1 [Titular]
Nombre DNI Direccin
[Tipo]
Cuenta Corriente
Cuenta de Ahorro
Intereses
)LJXUD 'LDJUDPD GH FODVHV GH XQ VLVWHPD EDQFDULR VHQFLOOR Las transiciones entre estados son mostradas mediante flechas rotuladas. El estado de inicio debe poseer una nica transicin saliente, correspondiente al servicio que se est modelando. Las transiciones debidas a acciones del usuario se rotulan mediante un smbolo de exclamacin seguido de la accin del usuario. Las transiciones debidas al resultado de una operacin se rotulan mediante una descripcin de la semntica del valor resultante de la operacin puesta entre parntesis, como en (no hay saldo). En este sentido, la operacin en cuestin se corresponde con el subestado de Busy del que parten estas transiciones. Finalmente, las transiciones debidas a un time-out se rotulan mediante el smbolo @ seguido del tiempo lmite, como en @ 5s. Las causas de transiciones pueden agruparse en expresiones mediante operadores DQG &, RU | y los parntesis necesarios para formar transiciones disparadas por motivos complejos, como en ! Volver | @ 5s. Tambin es posible mostrar los elementos de interface de usuario (vase %RFHWRV GH (OHPHQWRV GH ,QWHUIDFH GH 8VXDULR) asociados a cada estado colocando junto a los recuadros correspondientes los nombres de dichos elementos, como en DlgMensaje bajo Modal/NoHaySaldo. Del mismo modo, los parmetros de cada estado han de mostrarse junto al mismo, precedidos de un
Finalmente, las generalizaciones/especializaciones son mostradas mediante un pequeo tringulo de base horizontal, con su vrtice superior unido a las clases genricas, y su base unida a las clases especializadas. El criterio de especializacin o discriminante se muestra entre corchetes cerca de dicho tringulo.
'LDJUDPDV GH (VWDGRV GH 6HUYL FLRV

Un diagrama de estados de un servicio muestra la dinmica del sistema durante la ejecucin de un servicio determinado, en cuanto a los estados y transiciones que se pueden dar. La Figura 4 muestra un ejemplo de diagrama de estados de un servicio. Los estados son mostrados como recuadros con el nombre del estado en su interior. Los estados especficos derivados de los estados genricos se denotan mediante el nombre genrico seguido de una barra y el nombre especfico, como en Busy/Cargo. El estado de inicio del servicio se marca con dos cculos concntricos, mientras que el estado (o los estados) de final se marcan mediante un crculo con un punto en su interior. Pueden denotarse los estados compuestos mediante el smbolo # delante de su nombre.
SacarDinero Ready
.Cuenta: Cuenta
Modal/ PideCantidad ! Cancelar ! Aceptar

DlgCantidad
Busy/Cargo (ok)
[Ready.Cuenta.Saldo >= Modal/PideCantidad.DlgCantidad.Cantidad]
(no hay saldo) Modal/ NoHaySaldo ! Volver

DlgMensaje
Modal/ CojaDinero
DlgMensaje
#AlgoMs
! Volver | @ 5s
)LJXUD 'LDJUDPD GH (VWDGRV GHO 6HUYLFLR 6DFDU'LQHUR
!!
86Q6
punto y especificando su tipo, como en .Cuenta: Cuenta bajo Ready. Tanto los elementos de interface de usuario como los parmetros de los estados, as como los nombres de los estados Busy (actuando en vez del resultado devuelto de la operacin correspondiente) pueden utilizarse en aserciones que otros estados han de cumplir. Esta aserciones son mostradas entre corchetes prximas al estado en cuestin.
La Figura 6 muestra un ejemplo de diagrama de componentes. Cada componente es mostrado como un rectngulo con su nombre en el interior. Las relaciones entre componentes se muestran mediante lneas contnuas, indicando la cardinalidad de las mismas mediante nmeros cerca de cada componente. Las fronteras entre procesos se muestran mediante lneas de puntos, con los nombres de cada proceso a cada lado.
Interface de Usuario Estndar
1 1
%RFHWRV GH (OHPHQWRV GH ,QWHU IDFH GH 8VXDULR

Los bocetos de elementos de interface de usuario muestran diseos de cada elemento de interface de usuario, incluyendo los controles de cada uno, as como los parmetros no visibles para el usuario final que puedan existir. La Figura 5 muestra un ejemplo. El elemento de interface de usuario es mostrado de forma esquemtica y genrica, sin detalles especficos de ningn interface grfico en concreto. El nombre del elemento de interface de usuario se muestra sobre l. Los controles se muestran como formas dentro del elemento. Los textos que aparecen dentro de los controles, entre corchetes, indican el nombre y tipo de parmetros visibles (controles), como en [Cantidad: Integer]. Los textos que aparecen dentro de los controles sin corchetes corresponden a posibles acciones de usuario, como en Aceptar. Los dems textos mostrados dentro del elemento de interface de usuario han de tomarse literalmente, es decir, son textos que aparecern tal cual en el sistema. Finalmente, los parmetros no visibles del elemento aparecen bajo el mismo, precedidos por un punto, como en .Cuenta: Cuenta.
DlgCantidad
n 1 n
Servicio de Datos
1 1
Complemento
&OLHQWH 6HUYLGRU
n 1
Cliente de Base de Datos
Servidor de Base de Datos
)LJXUD 'LDJUDPD GH FRPSRQHQWHV
'LDJUDPDV GH &RODERUDFLyQ
Los diagramas de colaboracin muestran la dinmica de una operacin, en trminos de los objetos y mtodos involucrados en la ejecucin de la misma. La Figura 8 muestra un ejemplo. Los objetos se muestran como recuadros con el nombre del objeto y de la clase correspondiente en el interior. Las colecciones de objetos se muestran como dos recuadros solapados, anteponiendo la palabra col al nombre de la clase, como en ts: col Tarjeta. Las colaboraciones entre objetos se muestran como flechas numeradas y rotuladas. Los nmeros de las colaboraciones, construidos con formato jerrquico (0., 1., 1.1., 1.2, 2., etc.) expresan secuencia, mientras que los rtulos muestran el nombre y argumentos de cada colaboracin. Las colaboraciones con colecciones pueden llevar una clusula de restriccin (como [.Cdigo =1 CdigoTar]), mostrada entre corchetes junto a la coleccin en cuestin, para expresar qu elementos de la coleccin reciben la peticin. En ausencia de esta clusula, se entiende que todos y cada uno de los elementos de la coleccin la reciben, excepto en el caso de una operacin new (vase ms adelante). Pueden utilizarse atributos de los objetos de la coleccin precedindolos de un punto, como .Cdigo. Puede utilizarse un signo de cardinalidad para matizar el carcter de las aserciones; por ejemplo, =1 en [.Cdigo =1 CdigoTar] indica que ha de existir 1 y slo 1
Cantidad a sacar:
[Cantidad: Integer]
Introduzca la cantidad a sacar y pulse Aceptar para proceder.
Aceptar .Cuenta: Cuenta
Cancelar
)LJXUD %RFHWR GHO HOHPHQWR GH LQWHUIDFH GH XVXDULR 'OJ&DQWLGDG
'LDJUDPDV GH &RPSRQHQWHV
Los diagramas de componentes muestran la estructura de un sistema o un componente en cuanto a sus componentes o sub-componentes y a las relaciones entre ellos. Son una versin simplificada de los diagramas de clases (vase 'LDJUDPDV GH &ODVHV).
!"
CompruebaPin
1. b: Banco
LeePin
ts: col Tarjeta

(CdigoTar)
el caso de los diagramas de colaboracin (vase 'LDJUDPDV GH &RODERUDFLyQ).
Las visibilidades se representan mediante flechas desde la clase en cuestin hacia los objetos visibles por ella. Las new referencias dinmicas se r: Registro muestras mediante lnea de (CdigoTar, puntos (como en "Comprobar PIN", Resultado) p:Programa), mientras que las permanentes se representan mediante lnea contnua. Las Registra(r) referencias exclusivas se his: Historial muestran mediante un doble recuadro en torno al objeto referenciado (como en discos: )LJXUD 'LDJUDPD GH FRODERUDFLyQ SDUD OD RSHUDFLyQ &RPSUXHED col Disco), mientras que la au3LQ sencia de dicho doble recuadro elemento de la coleccin que cumpla la condiindica referencia compartida. Una doble flecha cin. indica referencia con ligazn (como en cpu: const CPU), mientras que una flecha sencilla inLa creacin de nuevos objetos se seala medica referencia no ligada. Finalmente, la palabra diante la colaboracin especial new, como en const antepuesta al nombre de la clase del obr: Registro. Una operacin new sobre una jeto referenciado indica referencia constante, coleccin no es recibido por cada objeto de la comientras que su ausencia indica referencia varialeccin, si no que crea un objeto en esa coleccin; ble. por lo tanto, la operacin especial new no pue3. 2.
[.Cdigo =1 CdigoTar]
(CdigoTar, Pin)
de llevar asociada ninguna clusula de restriccin. De modo similar, la eliminacin de objetos se seala mediante la colaboracin especial delete.
6HXGRFyGLJR
El seudo-cdigo es utilizado para mostrar los interfaces de las clases, as como para completar los diagramas de colaboracin (vase 'LDJUDPDV GH &RODERUDFLyQ). El seudo-cdigo debe ser semiformal, es decir, poseer un grado de formalidad que permita expresar la funcionalidad requerida sin ambigedades, pero proporcionando a la vez una flexibilidad mayor que la de los lenguajes de programacin habituales. A continuacin se muestra el seudo-cdigo correspondiente al diagrama de colaboracin mostrado en la Figura 8.
'LDJUDPDV GH 9LVLELOLGDG
Los diagramas de visibilidad muestran las posibilidades de acceso desde una clase hacia otros objetos, y caracteriza el tipo de cada va de acceso.
Ordenador
discos: col Disco
p: Programa
cpu: const CPU
)LJXUD 'LDJUDPD GH YLVLELOLGDG SDUD OD FODVH 2UGHQDGRU La Figura 7 muestra un diagrama de visibilidad. La clase a la cual corresponde el diagrama se representa mediante un recuadro con su nombre en el interior. Cada objeto o coleccin de objetos visibles por dicha clase se representan como recuadros o recuadros solapados, con sus nombres en su interior, usando la misma notacin que en
!#
86Q6
rhv Banco.CompruebaPin(CdigoTar, Pin): 7yrh vs

// prepara resultado segn coincida el PIN o no. hResultado: 7yrh
*/26$5,2
A continuacin se ofrecen explicaciones de algunos de los trminos utilizados en el texto. Tngase en cuenta que las explicaciones proporcionadas se refieren al contexto especfico de la metodologa Metis.
Upv
6p
ur
ts[CdigoTar].Pin == Pin Resultado = Ur Resultado = Ahyr
// 1.1.
ryr rq
@yvphpvy
@vqhq rrh h vrh r vrhp~h p py Utvphrr hv uh qvvv uhq hrvrhshr Sryhpvyqvrppvhy p rivph qr hrqrrhpyhrprh hpyhrprr Sryhpvytrpvph qvrppvhyrr qpyhr Qvrqhqrphyhqrhpyhr Srvppvypvphryhvhhyhh vpvhpvy qr iwr r h ryh pvy 8w qr vrhppvr rr vrh i hpr qvvtvq uhpvhyhprppvyqrhyt~iwrv rrptsvp 6ihppvyrvhyrrhppr qryqvvqrhyvphpvy Vvqhq qr hihw p iwrv r vyrrh pw qr phhph tvphqrrvhq @v rphthq qr rpviv r h qr phiv qrpvqv hprph qr ryyh Qhr qr vrh p rvqhq r phy spvhy vh V p rr rqr rh pvvq qr iprr Qhr qr yh spvhyvqhq qry vrh p hyh vrqrrqrpvh vrh ryhvhhr vqrrqvrr qr rtrqrspvhyvqhq 9prsqhrhyrrihhq rhpvyviyyvphrhy 9pr r hphxh h vrh qvvtvq hy hv svhy qry v 8prpvy hrvhy qr ryhq hyrrrshqrqpr prpvhyirhryrhh yyh Tipw qr yh rhyvqhq irhqh qr vrp hh yh pppvy qr vrh Sryhpvy rrhqh p h qr ryhpvr ivhvh Q rwry r h rrpvhyvhpvy uh h rv hyrrivhvpryqpqry ~r qr rpyhr yvyvphq ry~rqripyhr Sryhpvyqvrppvhy p rivph qr rpyhripyhr rr h i rpyhrhiipyhr 8vphpvy hyvph rr q h rVrrrrirqr pvv rqr yyrh vshpvy hpvhqh @r r hr qr hp r qvvtruhpvhvrh
// registra acceso. hr: rRegistro( CdigoTar, "Comprobar PIN", Resultado ) His.Registra(r) // devuelve resultado. r Resultado
6trthpvy
// 1.2. // 1.3.
6pvhpvy 6vi 8hqvhyvqhq 8hqr
rq
ruqHistorial.Registra(r: Registro) rq
// simplemente aade el registro al historial. Registros.6qq r
Para mostrar el interface de una clase, se utilizan solamente los encabezados de las operaciones, como en el ejemplo siguiente.
8yhr 8vpyqrqrh yy 8vvyqr pyqr phiv 8rr
rhv Banco.CompruebaPin(CdigoTar, Pin): 7yrh rhvBanco.ConsultaSaldo(CdigoCuenta): InfoSaldo rhvBanco.SacaDinero(CdigoCuenta, Cantidad): 7yrh rhvBanco.IngresaDinero(CdigoCuenta, InfoIngreso): 7yrh
La sintaxis del lenguaje utilizado no est fijada, pero se recomienda el estilo utilizado en los ejemplos anteriores. Las palabras en negrita son palabras clave del seudo-lenguaje. Aunque generalmente es adecuado especificar los detalles de la implementacin al mximo, reduciendo la funcionalidad de cada operacin o mtodo a expresiones basadas en dichas palabras clave, tambin es posible abstraer los detalles mediante el uso de comentarios o texto libre intercalado.
8wqr phhprtvph 9vhthh 9prhpvy qrhv 9pr
&yGLJR )XHQWH
Cdigo fuente escrito en el lenguaje apropiado.
9vvqr hyvphpvy @vhyrr ivhvqrh ryhpvy
@rpvhyvhpvy @r
@rqrr hqh
!$
Upv
@rqrhyv qh Apvy Brrhyvhpvy Bqrr vrpvh
@yvphpvy
@r r hr qr vrh r qvvtruhpvhhp Uvqrhrhrrqrrhyvhrr ry r qry prqvvr trrhy qr Hrv Sryhpvy vrh h yh rrpvhyvhpvy privphqripyhrrpyhr 8wqrpyhrrhyhprh qhrprhqhwhqr hyh pp rvrr Ihyrr p vr pyhr rrpuhrr ryhpv hqhrryqvvqrhyvphpvy 8hhprtvph vh qr t qr rvrpvh r rvr rsrvr h vhpvhrrptsvphqrqvput 8w qr rhpvr qr p rr 8wqrrvpvqrvrh Psrh rhyvhqh h pyhr r p v qr vphpvyrrh r yrqrrvyvhqh qvpuhpyh r Srrrhpvy qr vrh p hythvrpvhyvqhqrrptsvph 8hhpvqhqqryiwrqrhpyhr hvpvhr r h ryhpvy hh p pryhyhryhrhvpvh Vhryhpvyr hrthiyrr r vq v y iwr qr yh pyhr vtr rryrvqrprvyppryh yhqryhrshhr Dhpvhqrhpyhrhpvhiyrh iwr prpvhy qr yh rhyvqhq irhqh Psrhrhyvhqhprr h pyhr r pv qr vph pvyrrh r rqr r vyv hqhpyvrrrr 8hhpvqhqqryhvshpvyqrir vv rr qvsrrr rwrppvr qr vrh Dvpvhvh qvvtvqh h yh qvsvphpvy qr y rvv qr vrh h r ruhvqprhq 8hhprtvphqrhpyhrhrh hviivrhryhpvy Aryr qr vvqhq rphy rr pyhr Qrqr r h hpvh pvy h htrthpvy ivr h r rpvhyvhpvy 8w qr phyvqhqr rpvyyh h prvqh rvsvphiyr r vrh uh qr rr hh r pv qrhqprp Qqpirvqhhvqryhrwrp pvyqrhspvy Qhryrrptsvprrqrhh pyhrihwpvrhpqvpvr Psrh rhyvhqh vrh prr r pv qr vph pvyrrh r rqr r vyv hqpyvrrrr Qqp vsivp r r hh qr pvhhryqrhyyqryphy rvyvhyhrqytthHrv Dhpvh qr h ryhpvy r yh r vrvrriwrppr
Upv
Vhv
@yvphpvy
Qrhtqrrhrvyv h vrh 6 rq r ryrh p s vtvsvphq r rhyvqhq shv
Dqrvsvphqqr rvrpvh Drshprqry prr Drshprqry vrh Hpq
Hqry Ihrthivyvqhq qrhryh pvy
Piwr Prhpvy
Qrvrpvh Qrhqr phiv Qvrqhq Sryhpvy
Srvvqry vrh Sryhq Sy Trvpv
Tvrh Uyh
!%
86Q6
%,%/,2*5$)$
Booch, G. 1994. Object-Oriented Analysis and Design with Applications, 2nd edition. Redwood City: Benjamin/Cummings. Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes, F. y Jeremaes, P. 1994. Object-Oriented Development: The Fusion Method. New Jersey: Prentice-Hall. Cotton, T. 1996. Evolutionary Fusion: A Cutomer-Oriented Incremental Life Cycle for Fusion. En Malan, R., Letsinger, R. y Coleman, D. 1996. 2EMHFW2ULHQWHG 'HYHORSPHQW DW :RUN )XVLRQ LQ WKH 5HDO :RUOG. Upper Saddle River: Prentice-Hall. Gamma, E, Helm, R, Johnson, R y Vlissides, J. 1995. Design Patterns: Elementos of Reusable Object-Oriented Software. Reading: Addison-Wesley. Gonzlez Prez, C. A. 1999. Diseo y Construccin de Sistemas de Informacin para la Gestin de Recursos Culturales. Tesis doctoral, en preparacin. Malan, R., Letsinger, R. y Coleman, D. 1996. Object-Oriented Development at Work: Fusion in the Real World. Upper Saddle River: Prentice-Hall. McConnell, S. 1996. Rapid Development. Redmond: Microsoft Press. Meyer, B. 1997. Object-Oriented Software Construction, 2nd edition. Upper Saddle River: Prentice-Hall. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. y Lorensen, W. 1991. Object-Oriented Modeling and Design. Englewood Cliffs: Prentice-Hall.
!&
7tWXORV 3XEOLFDGRV
&$3$ &$3$ &$3$ &$3$ &$3$ &$3$ &$3$ &$3$ &$3$ 8Q 0RGHOR GH (YDOXDFLyQ GH ,PSDFWR $UTXHROyJLFR (O 3DUTXH (yOLFR GH &DUHyQ &RQWULEXFLyQ D XQ 6LVWHPD GH 5HJLVWUR GH <DFLPLHQWRV $UTXHROyJLFRV HQ *DOLFLD 6,$ 0DQXDO GH 8VXDULR /D $UTXHRORJtD HQ OD *DVLILFDFLyQ GH *DOLFLD 3URJUDPD GH &RQWURO \ &RUUHFFLyQ GH ,PSDFWR 'HO 7HUUHQR DO (VSDFLR 3ODQWHDPLHQWRV \ 3HUVSHFWLYDV SDUD OD $UTXHRORJtD GHO 3DLVDMH &ULWHULRV \ &RQYHQFLRQHV SDUD OD *HVWLyQ \ HO 7UDWDPLHQWR GH OD &XOWXUD 0DWHULDO 0XHEOH (O 5HJLVWUR GH OD ,QIRUPDFLyQ HQ ,QWHUYHQFLRQHV $UTXHROyJLFDV 7HFQRORJtDV GH OD ,QIRUPDFLyQ \ 3DWULPRQLR &XOWXUDO (O 3DUDGLJPD 2ULHQWDGR D 2EMHWRV 7HFQRORJtDV GH OD ,QIRUPDFLyQ \ 3DWULPRQLR &XOWXUDO 8QD 0HWRGRORJtD ,QWHJUDO 2ULHQWDGD D 2EMHWRV SDUD 'HVDUUROOR GH 6RIWZDUH
3Uy[LPRV 7tWXORV
&$3$ &$3$ &$3$ (VSHFLILFDFLRQHV GH (VWLOR \ &RPSRVLFLyQ GH 7H[WRV HQ *,$U3D $UTXHRORJtD GHO 3DLVDMH \ 5HYDORUL]DFLyQ (O 3UR\HFWR GH ORV 0LOLDULRV GH /DPDV FRPR HMHPSOR /D $UTXHRORJtD GH OD $UTXLWHFWXUD GHVGH OD $UTXHRORJtD GHO 3DLVDMH )RUPD )XQFLyQ \ 3HQVDPLHQWR6HQWLGR HQGHO (VSDFLR $UTXLWHFWyQLFR.
!'
86Q6
1RUPDV GH 3XEOLFDFLyQ
7HPiWLFD &DSD
Esta serie publica trabajos sobre criterios, convenciones, y tcnicas de trabajo en Arqueologa. Las aportaciones que se irn ofreciendo en los diferentes cuadernos de la serie tienen por objeto construir una tecnologa para la evaluacin y gestin del Patrimonio Arqueolgico. Con ello se pretende contribuir al desarrollo, discusin y establecimiento de un estndar de prctica arqueolgica.
$GPLVLyQ GH 2ULJLQDOHV
Se admitirn para su publicacin los trabajos que sean presentados y aprobados por el Comit Editorial siempre que se ajusten a la temtica anterior y a las normas que aqu se establecen. Los originales sern revisados por un grupo de evaluadores que informarn sobre la pertinencia de su publicacin y recomendarn cuantas modificaciones crean convenientes para incluir el trabajo dentro de las series. En todo caso la correspondencia con los autores se realizar desde el Comit Editorial. Los trabajos sern remitidos a la secretara de Capa y Tapa, y tendrn como fechas lmites para su entrega el 30 de Abril y 30 de Octubre de cada ao. A los autores se les enviar una prueba del documento para que sea revisado antes de su publicacin, con la recomendacin de que realice las correcciones sugeridas. Una vez sean publicados se le remitirn dos ejemplares, independientemente del nmero de autores firmantes. Los autores podrn solicitar ejemplares adicionales previo pago de los mismos.
1RUPDV GH )RUPDWR
Los trabajos se podrn realizar en cualquier idioma, pero siempre tendrn que llevar un resumen/abstract y palabras clave/keywords en ingls. En el caso de que el trabajo estuviese en ingls, estos irn en un segundo idioma. Tendrn una extensin mnima de 25.000 palabras y una mxima de 40.000, 50 pginas a una columna con tamao de letra 10, interlineado sencillo, incluyendo el espacio para las figuras. Irn precedidos de una hoja donde se indiquen: ttulo, nombre del autor, direccin, telfono, correo electrnico (si lo tiene), y fecha de envo del trabajo. Se enviarn en soporte digital, aparte de dos copias en papel. Se deben de enviar preferentemente en Microsoft Word y si no fuese posible en un programa compatible. Dado el carcter de ambas series, se recomienda emplear una parte grfica lo ms amplia posible. Se recuerda que toda la publicacin ser en B/N, por lo que las figuras debern ser elaboradas en funcin de ello. Los ttulos se tendrn que diferenciar fcilmente del texto y entre ellos, pudiendo ir numerados. Los diferentes apartados: anexos, apndices, etc..., debern ir precedidos de un salto de pgina. Los cuadros, mapas, grficos, ... se presentarn preferentemente en soporte digital y, adems y en cualquier caso, copia impresa en papel de calidad y numeradas al dorso. Se sealar a lpiz en el margen del texto el lugar sugerido para su ubicacin de cada una de las figuras. Los pies de figura se colocarn en una hoja aparte indicando claramente a que figura pertenece. Las notas debern de ir al pie, y su numeracin debe de ser continua. La bibliografa se colocar al final del documento, ordenndola alfabticamente y adaptndose a los siguientes ejemplos: &ULDGR %RDGR ) $PDGR 5HLQR ; \ 0DUWtQH] /ySH] 0 & 5HG GH *DVLILFDFLyQ GH *DOLFLD &RUUHFFLyQ GHO ,PSDFWR $UTXHROyJLFR 5HYLVWD GH $UTXHRORJtD 0DGULG $ULDV 9LODV ) &DYDGD 1LHWR 0 *DOLFLD EDMRUURPDQD *DOODHFLD 6DQWLDJR GH &RPSRVWHOD +DUULV (& 3ULQFLSLRV GH (VWUDWLJUDItD $UTXHROyJLFD %DUFHORQD &UtWLFD (G RULJLQDO LQJOHVD GH

Capa11 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capa11 PDF

Uploaded by

Copyright:

Available Formats

&ULWHULRV H &RQYHQFLyQV HQ $UTXHROR[tD GD 3DLVD[H

7HFQRORJtDV GH OD ,QIRUPDFLyQ \ 3DWULPRQLR &XOWXUDO 

8QD 0HWRGRORJtD ,QWHJUDO 2ULHQWDGD D 2EMHWRV SDUD 'HVDUUROOR GH 6RIWZDUH

7$%/$ '( &217(1,'2

86Q6 UrpytthqryhDshpvyQhvv 8yhy!)VhHrqytthDrthyPvrhqhh Piwrhh9rhyyqrTshr 8ph6BiyrQpr Ghihvqr6rythrAh8yhv VvrvqhqrqrThvhtqr8ryh Qvrh@qvpvy

PirpvyqrSrv v 8yqr8hiv 6iyvvqr6yIvry 9vrx6vrpyvp qr6yIvry @qvUrpyytvp Qyhvsvphpvy

Irprvqhqr 9vppvhvqryTv rh SrvvqryTv rh Qrhqr8h iv

8yqr8hiv 8srppvyqryh9prhpvyqrVhv 9vrx 6iyvv qr6yIvry 6vrpyvp qr6yIvry 8vpyqr 9rhyy!

9vrx 6iyvv qr7hwIvry 6vrpyvp qr7hwIvry

$QiOLVLV GH $OWR 1LYHO

'LVHxR $UTXLWHFWyQLFR GH $OWR 1LYHO

llevar a la prctica diseos tericos en un dominio de aplicacin especfico.

revisin de los resultados obtenidos en esta fase de planificacin.

&RQIHFFLyQ GH OD 'RFXPHQWDFLyQ GH 8VXDULR

$QiOLVLV GH %DMR 1LYHO

'LVHxR $UTXLWHFWyQLFR GH %DMR 1LYHO

resultados a obtener se hallan estrechamente relacionadas con el mencionado diseo de detalle.

2. Validar id. Final si no es vlido.

Entrada 1 (id) (2) Salida 2 (informacin asociada) Salida 3

Nombre DNI Direccin

'LDJUDPDV GH (VWDGRV GH 6HUYL FLRV

Modal/ PideCantidad ! Cancelar ! Aceptar

(no hay saldo) Modal/ NoHaySaldo ! Volver

)LJXUD  'LDJUDPD GH (VWDGRV GHO 6HUYLFLR 6DFDU'LQHUR

%RFHWRV GH (OHPHQWRV GH ,QWHU IDFH GH 8VXDULR

Cliente de Base de Datos

Servidor de Base de Datos

)LJXUD  'LDJUDPD GH FRPSRQHQWHV

Aceptar .Cuenta: Cuenta

)LJXUD  %RFHWR GHO HOHPHQWR GH LQWHUIDFH GH XVXDULR 'OJ&DQWLGDG

ts: col Tarjeta

el caso de los diagramas de colaboracin (vase 'LDJUDPDV GH &RODERUDFLyQ).

discos: col Disco

cpu: const CPU

rhv Banco.CompruebaPin(CdigoTar, Pin): 7yrh vs

ts[CdigoTar].Pin == Pin Resultado = Ur Resultado = Ahyr

6pvhpvy 6vi 8hqvhyvqhq 8hqr

8yhr 8vpyqrqrh yy 8vvyqr pyqr phiv 8rr

8wqr phhprtvph 9vhthh 9prhpvy qrhv 9pr

Dqrvsvphqqr rvrpvh Drshprqry prr Drshprqry vrh Hpq

Hqry Ihrthivyvqhq qrhryh pvy

Qrvrpvh Qrhqr phiv Qvrqhq Sryhpvy

Srvvqry vrh Sryhq Sy Trvpv

You might also like

7HFQRORJtDV GH OD ,QIRUPDFLyQ \ 3DWULPRQLR &XOWXUDO

86Q6 UrpytthqryhDshpvyQhvv 8yhy!)VhHrqytthDrthyPvrhqhh Piwrhh9rhyyqrTshr 8ph6BiyrQpr Ghihvqr6rythrAh8yhv VvrvqhqrqrThvhtqr8ryh Qvrh@qvpvy

PirpvyqrSrv v 8yqr8hiv 6iyvvqr6yIvry 9vrx6vrpyvp qr6yIvry @qvUrpyytvp Qyhvsvphpvy

Irprvqhqr 9vppvhvqryTv rh SrvvqryTv rh Qrhqr8h iv

'LDJUDPDV GH (VWDGRV GH 6HUYL FLRV

)LJXUD 'LDJUDPD GH (VWDGRV GHO 6HUYLFLR 6DFDU'LQHUR

%RFHWRV GH (OHPHQWRV GH ,QWHU IDFH GH 8VXDULR

)LJXUD 'LDJUDPD GH FRPSRQHQWHV

)LJXUD %RFHWR GHO HOHPHQWR GH LQWHUIDFH GH XVXDULR 'OJ&DQWLGDG

8yhr 8vpyqrqrh yy 8vvyqr pyqr phiv 8rr

Hqry Ihrthivyvqhq qrhryh pvy