Alita Cursillo Completo de Ingenieria Del Software

Alita Mini Cursillos Hispaninglis

(pÁ ayudá a la pipol OLE)

“COMO SOBREVIVIR A I!EIERIA "EL SO#$%ARE &OC ' O MORIR E EL I$E$O

“LO MEJOR DE LA UOC es QUE PODEMOS AYUDAR A NUESTROS COMPAÑEROS, PORQUE SIN SOLIDARIDAD NO SOMOS NADA.” [ALITA]

CONSEJOS DE ALITA PARA APROBAR FACILMENTE INGENIERIA DEL SOFTWARE Si aceptais unos consejos para esta asignatura, los apuntes no sirven “para nada”... ES IDEAL tirarlos al contenedor azul de reciclaje de papel dado que solo sirven para hacer que la gente suspenda.

A lo largo del curso habr dos deba!es de aula" #ue !a$%oco s&r'e( %ara (ada" escr&b&r u( $e(sa)e o dos e( %la( co%* %as!e * a correr" es u(a !o!al &(u!&l&dad * %+rd&da de !&e$%o, Lo $e)or so( los a%u(!es de u(os co$%a-eros de a#u. de la CA/OC #ue h&c&ero( u(os res0$e(es de $&edo 1F&s!a(da(!&lus"Ice * 2u$&34,,, * los e3$e(es de es!a ul!&$a co('oca!or&a de J/NIO del 5677" (o os $&r+&s (ada $s,,, No os %o(ga&s a colecc&o(ar e3$e(es de o!ros a-os %or#ue desde hace u(os %ocos se$es!res los e3$e(es ha( ca$b&ado" * los e3$e(es a(!&guos solo 'a( a ser'&r %ara l&aros, La es!ruc!ura de las PACS so( 5 %acs #ue la ge(!e se 'ol'er loca %ero co( la a*uda de la CA/OC las sacare&s seguro" * des%u+s dos %rc!&cas" la 0l!&$a es es%ec&al$e(!e %u-e!era %or#ue !&e(e cos&!as de bases de da!os" %ero sacar u(a B o u( C8 e( la e'aluac&9( co(!&(ua es $u* :c&l * as. *a a%rob&s co( u( C; 1<"=4 e( el e3a$e(, El !e$a es &r al gra(o e( el es!ud&o de la as&g(a!ura" os lo e3%l&co a co(!&(uac&9(, El e3a$e( es es!o>

1. La teor!a en el e"a#en solo vale 1 punto $ se repite, es un regalito. Sie#pre cae lo #is#o. %. 1,& puntos de diagra#a de estados' ()*+ADISI-, es el ejercicio #s /cil que os podis i#aginar. 0. *nos %,& puntos de diagra#a de clases' ha$ que tener ojo con la asociativas etc... . *nos %,& puntos de diagra#a de DIA23AA DE (AS-S DE *S-, aqu! ha$ que sa4er #u$ 4ien lo que es e"tend e include. &. *nos %,& puntos de diagra#a de secuencia 5$ rara vez sale de Actividades6.

EN EL DOC/MENTO ,2IP ?/E ADJ/NTO A ESTE MENSAJE EST@ TODOOOOO LO ?/E NECESITAIS PARA LA ASIGNAT/RA" PERFECTAMENTE RES/MIDO * co(ce(!rado" &(cluso u( $a(ual de MAGIC DRAW de &(&c&o,

7o necesitais nada #s para apro4ar la asignatura con notaza, #ucha suerte, aqu! esto$ para a$udar a toda la 4uena gente que su/re en silencio en la *-(, ALI8A

Espai grapa

Assignatura

Codi

Data

Hora inici

Enginyeria del programari

05.060

11/06/2011

09:00

Ì05.060Â11Â06Â11ÂEXEÎ 05.060 11 06 11 EX

Enganxeu en aquest espai una etiqueta identificativa amb el vostre codi personal Examen

Fitxa tècnica de l'examen •

Comprova que el codi i el nom de l’assignatura corresponen a l’assignatura en la qual estàs matriculat.

•

Només has d’enganxar una etiqueta d’estudiant a l’espai corresponent d’aquest full.

•

No es poden adjuntar fulls addicionals.

•

No es pot realitzar la prova en llapis ni en retolador gruixut.

•

Temps total: 2 h.

•

En cas que els estudiants puguin consultar algun material durant l’examen, quin o quins materials poden consultar? Cap

•

Valor de cada pregunta: Veure enunciat

•

En cas que hi hagi preguntes tipus test: Descompten les respostes errònies?

•

Indicacions específiques per a la realització d’aquest examen: -

Enunciats

Pàgina 1 de 6

NO

Quant? -

Assignatura

Codi

Data

Hora inici


05.060

11/06/2011

09:00

Exercici 1: Teoria (10%) Què és un cicle de vida iteratiu i incremental? Per què és millor que el cicle de vida en cascada? Mòdul 1, apartat 2.2

Pàgina 2 de 6

Assignatura

Codi

Data

Hora inici


05.060

11/06/2011

09:00

Exercici 2: Diagrama de Classes (25%) Representa mitjançant un diagrama de classes la següent informació relativa a un servei municipal d’autobusos (anomenats habitualment busos): Dels busos se n’indica el número, la matrícula, la marca, i la mida (gran o petit). Dels conductors en coneixem el DNI, el nom, la data de naixement i una marca que indica si està de baixa. Hi ha dos tipus de parades: les ordinàries i les de descans; unes i altres tenen codi, adreça i una marca que indica si la parada està anul·lada. Les parades de descans tenen, a més, la capacitat, que és el nombre de busos grans que hi poden aparcar per al descans dels conductors. Una línia es descriu pel número, nom, tipus de calendari (diari, feiners, platja o curs escolar), interval de pas en minuts i les parades que la componen (que poden ser compartides per múltiples línies), almenys 2, amb el número d’ordre de cada parada dins la línia. Tota línia inclou almenys una parada de descans, que ha de tenir el número 1; la resta poden ser ordinàries o de descans. Com a informació comuna a totes les línies hi ha les dates d’inici de fi dels calendaris de curs escolar i de platja. Cada bus pot estar assignat a una línia com a màxim i cada línia pot tenir assignats d’un a 3 busos. Els conductors dels busos treballen per torns, dels quals coneixem la data i número de torn (1, 2 o 3). Un bus en un torn pot ser conduït per un conductor com a màxim, un conductor en un torn pot conduir un bus com a màxim i un conductor pot conduir el mateix bus en qualsevol nombre de torns o en cap.

L’ordre de les parades dins d’una línia també es pot indicar per mitjà de la propietat ordered a l’extrem de la parada. En tal cas, Parada i ParadaLinia poden ser simples associacions, no és imprescindible que siguin classes associatives.

Pàgina 3 de 6

Assignatura

Codi

Data

Hora inici


05.060

11/06/2011

09:00

Exercici 3: Diagrama de casos d’ús (25%) Es vol elaborar un diagrama de casos d’ús que representi el funcionament parcial d’una clínica veterinària sota els següents supòsits. La clínica disposa d’una secretària que realitza la gestió dels clients, que inclou tant crear-ne la fitxa com modificar-la; en aquest últim cas cal cercar el client. El veterinari pot realitzar les mateixes tasques que la secretària. A més, quan realitza la revisió de l’animal dóna d’alta la revisió, procés que podrà requerir la cerca del client. Quan es fa una revisió, de la mateixa manera que passa quan es fa la gestió dels clients, s’envia una notificació al client informant-lo de la gestió realitzada. Tant la secretària com el veterinari han d’autentificar-se en el sistema per a poder utilitzar-lo. El sistema té un temporitzador que imprimeix els clients del sistema tots els divendres de l’any.

També es podria haver considerat l’actor no primari Client, donant la solució per correcta.

Pàgina 4 de 6

Assignatura

Codi

Data

Hora inici


05.060

11/06/2011

09:00

Exercici 4: Diagrama de Seqüència (25%) Es vol elaborar un diagrama de seqüència que representi el procés iteratiu de validació de la recaptació dels autobusos assignats a un gestor de la empresa municipal de transports. En entrar al sistema el gestor s’identifica introduint el seu codi d’usuari. A continuació, per a cadascun dels autobusos que té assignats, introdueix per pantalla el codi de l’autobús del qual vol obtenir la recaptació. En aquest moment, el controlador del sistema rep una crida per a cercar l’autobús que correspongui al codi introduït. Un cop recuperat, en consulta la recaptació per a la data que el controlador indiqui (que serà la del dia anterior a la data actual). La recaptació de cada autobús se suma a la ja obtinguda d’altres autobusos que el gestor té assignats i es mostra en pantalla el resultat de la suma. Una cop finalitzada l’obtenció de la recaptació total dels autobusos del gestor, aquest compara l’import total obtingut amb l’import total calculat manualment pels conductors. Si el gestor està conforme, confirma polsant damunt la pantalla. Llavors es llança una crida al controlador informant de la recaptació i la data en la qual es vol facturar. El controlador, per acabar, realitza la facturació de la recaptació per a la data indicada. En cas de no estar conforme, el gestor cancel·la el procés polsant damunt la pantalla, cosa que envia al controlador la crida que cancel·li el procés, indicant el codi de gestor i la data, i a més notifica al sistema de frau que el gestor ha detectat un problema per a aquella data.

Pàgina 5 de 6

Assignatura

Codi

Data

Hora inici


05.060

11/06/2011

09:00

Exercici 5: Diagrama d’estats (15%) Es vol elaborar un diagrama d’estats sota el següent supòsit. En iniciar el sistema es produeix un esdeveniment iniciar que condueix a l’estat A. Quan es compleix que va>vb se surt de l’estat anterior i es passa a l’estat compost B. B conté dues seqüències de subestats. El primer subestat d’una de les seqüències és BA, del qual se surt quan es produeix l’esdeveniment sortirBA, i aleshores s’executa exeBA() i es passa al següent subestat de la seqüència, BB, del qual se surt quan es produeix l’esdeveniment fiBB. L’altra seqüència té com primer subestat BC, del qual se surt després de 2 minuts per a passar als subestats BD i BE alhora. De BD se surt quan es produeix l’esdeveniment esborrar i llavors s’invoca a l’operació delete de l’objecte a; del subestat BE se surt quan es produeix l’esdeveniment callBC, i llavors es passa al subestat BF, del qual se surt passat un segon. Després de sortir tant de BD com de BF acaba aquesta seqüència. En aquest punt es valida si es compleix la condició avançaB, i en aquest cas es torna a l’estat compost B, o si en lloc d’això es compleix la condició avançaC, es passa a l’estat C, del qual se surt quan es produeix l’esdeveniment fi, amb el qual acaba el procés.

Pàgina 6 de 6

Espai grapa

Examen 2010/11-2 Assignatura

Codi

Data

Hora inici


05.060

18/06/2011

18:30

Ì05.060Â18Â06Â11ÂEXÈÎ 05.060 18 06 11 EX




•


•


•


•

Temps total: 2 h.

•


•


•


•


Enunciats

Pàgina 1 de 6

NO

Quant? -


Codi

Data

Hora inici


05.060

18/06/2011

18:30

Exercici 1: Teoria (10%) Descriu els problemes de qualitat i de productivitat en l’enginyeria del programari Mòdul 1, apartat 1.4

Pàgina 2 de 6


Codi

Data

Hora inici


05.060

18/06/2011

18:30

Exercici 2: Diagrama de Classes (25%) Representa mitjançant un diagrama de classes la següent informació relativa a un centre de rehabilitació: De tipus d’aparells per a la rehabilitació n’hi ha dues categories: fixos i portàtils; cada tipus té un nom. Els aparells dels tipus fixos s’identifiquen per un codi i poden pertànyer a diversos tipus fixos, mentre que els aparells dels tipus portàtils no estan identificats individualment i només tenen un tipus, el qual indica l’estoc d’aparells d’aquell tipus. Dels pacients se’n coneix el DNI, nom, domicili i telèfon i cada pacient participa en almenys un programa de rehabilitació, del qual coneixem les següents dades: nom i número de col·legiat del metge responsable del programa, sengles textos sobre el diagnòstic i el tractament de rehabilitació que ha de seguir el pacient, la durada en setmanes del programa de rehabilitació, el nombre de vegades per setmana que el pacient ha de fer el tractament i el nom del tipus d’aparell necessari per realitzar-lo. Cada programa de rehabilitació conté sessions, almenys una, cadascuna amb data i hora (duren una hora i comencen a una hora en punt). Una sessió pot formar part de fins a 3 programes de rehabilitació. En una sessió es pot fer servir com a màxim un aparell. Al centre de rehabilitació hi treballen monitors, que s’identifiquen pel nom, treballen en un torn (matí o tarda) i poden ajudar els pacients a fer servir els aparells durant les sessions; també poden escriure un text sobre incidències en l’ús d’un aparell durant una sessió en la qual hagin intervingut. En una sessió un monitor pot ensenyar a fer servir un aparell com a màxim, en l’ús d’un aparell durant una sessió hi pot intervenir un monitor com a màxim i un monitor determinat pot ensenyar a usar un aparell determinat en qualsevol nombre de sessions o en cap. Hi ha una informació comuna a tots els monitors, que és un avís de la Direcció.

Pàgina 3 de 6


Codi

Data

Hora inici


05.060

18/06/2011

18:30

Exercici 3: Diagrama de casos d’ús (25%) Es vol elaborar un diagrama de casos d’ús que representi el funcionament parcial d’una notaria sota els següents supòsits. El notari realitza la gestió notarial, que comporta l'alta d’un tràmit (essent els possibles tipus d’un tràmit una escriptura o un poder) o la modificació d’un tràmit. Tant en l’alta com en la modificació, s’ha de fer una notificació a Hisenda. La notaria té una secretària que té la funció d’enviar els tràmits als clients, funció que el notari pot realitzar també si la secretària no és a la notaria. Tant el notari com la secretària han d’identificar-se en el sistema per a poder utilitzar-lo.

També es podrien haver considerat els actors no primaris Client i Hisenda, donant-se la solució per correcta.

Pàgina 4 de 6


Codi

Data

Hora inici


05.060

18/06/2011

18:30

Exercici 4: Diagrama de Seqüència (25%) Es vol elaborar un diagrama de seqüència que representi el procés iteratiu que permet actualitzar les fitxes mèdiques dels pacients ingressats en un hospital, així com donar-los l'alta. El procés comença quan el metge veu per pantalla la llista dels pacients que té assignats. En aquest moment, selecciona un d’aquests pacients a través de la pantalla i aquesta fa una crida al controlador del sistema, que permet cercar al pacient a partir del seu DNI. Una vegada trobat el pacient, la pantalla en mostra la fitxa perquè el metge pugui actualitzar-la. Una vegada actualitzada, la pantalla invoca de nou el controlador perquè aquest actualitzi les dades del pacient. Un cop feta l’actualització, el controlador s’autoinvoca per a obtenir una recomanació d’alta o de permanència que es mostra per pantalla. Si el metge decideix donar d’alta el pacient, ha de polsar el botó corresponent dins la pantalla, i així invoca el controlador perquè doni l’alta mitjançant una crida al pacient, i tot seguit realitza la facturació en el subsistema corresponent mitjançant la invocació del mètode facturar, al qual se li passa el DNI del pacient. Si en canvi el metge decideix no donar d’alta el pacient, ha de polsar damunt el botó corresponent dins la pantalla i es passa al següent pacient, engegant-se un cop més tot el procés fins que s’acabi la llista dels pacients que el metge té assignats.

Pàgina 5 de 6


Codi

Data

Hora inici


05.060

18/06/2011

18:30

Exercici 5: Diagrama d’estats (15%) Es vol elaborar un diagrama d’estats sota el següent supòsit. En iniciar el sistema es produeix un esdeveniment inici que condueix a dos estats simultanis, B i A. De l’estat B se surt quan es compleix que va>vb, i llavors s'invoca el mètode cridarX(). L’estat A és compost i conté dues seqüències de subestats. En una d’elles el primer subestat és AA, del qual se surt passades 2 hores i aleshores s’invoca l’operació delete de l’objecte obj, finalitzant així aquesta seqüència. En l’altra seqüència el primer subestat és AB, del qual se surt quan es produeix l’esdeveniment callBC, passant al subestat AC, del qual se surt quan x >1, finalitzant així aquesta altra seqüència. Després de sortir dels estats B i A, es passa a l’estat C, del qual se surt quan es produeix l’esdeveniment validar. Si enlloc d’aquest esdeveniment, es produeix l’esdeveniment repetir i es compleix la condició sortir, es roman a l’estat C. Una vegada s’hagi sortit de C, si es compleix la condició exit es passa a l’estat D, i si es compleix la condició noExit es passa a l’estat E. De l’estat D se surt quan es produeix l’esdeveniment sortirD, i aleshores s'acaba el procés. De l’estat E se’n surt quan es produeix l’esdeveniment sortirE, amb el qual s’acaba el procés, també.

Pàgina 6 de 6

Espai grapa


Codi

Data

Hora inici


05.060

22/06/2011

12:00

Ì05.060Â22Â06Â11ÂEXVÎ 05.060 22 06 11 EX




•


•


•


•

Temps total: 2 h.

•


•


•


•


Enunciats

Pàgina 1 de 6

NO

Quant? -


Codi

Data

Hora inici


05.060

22/06/2011

12:00

Exercici 1: Teoria (10%) Descriu el cicle de vida amb prototipatge i la programació exploratòria. Mòdul 1, apartats 2.2.2 i 2.2.3

Pàgina 2 de 6


Codi

Data

Hora inici


05.060

22/06/2011

12:00

Exercici 2: Diagrama de Classes (25%) Descriu per mitjà d’un diagrama de classes la següent informació relativa al servei d’organització de cerimònies de casament d’un ajuntament: Els casaments són o bé civils o bé de ritus catòlic. D’uns i altres se’n coneix l’any en què es va registrar, un número correlatiu (que es calcula sumant 1 al darrer número assignat, que es conserva com a dada independent dels casaments), i la data, l’hora (una hora en punt) i els contraents, exactament dos. De cada contraent es es guarda el nom complet, el NIF o NIE, la data de naixement i el país de naixement (que és un d’una llista); tot contraent forma part d’un casament com a mínim. Dels casaments catòlics, a més, se’n guarda la següent informació: la indicació de si necessiten un capellà del poble, que per defecte és que sí, i una de les esglésies del poble, de les quals se’n coneix el nom, el segle i la seva capacitat. Per a un casament es pot encarregar opcionalment un àpat en algun dels restaurants del terme municipal. Dels restaurants es se’n coneix el nom, adreça, telèfon i nombre màxim de comensals; d’un àpat s’indica si serà dinar (sinó serà sopar) i el nombre de comensals. Per a un àpat es pot encarregar una actuació d’un conjunt musical local, cadascun dels quals té nom, preu per actuació i una llista de dates disponibles. Els conjunts musicals també poden actuar a l’església durant els casaments catòlics; un conjunt en una església pot actuar en qualsevol nombre de casaments (catòlics), un conjunt en un casament (catòlic) pot actuar com a màxim en una església, i en un casament (catòlic) i església pot actuar com a màxim un conjunt.

Pàgina 3 de 6


Codi

Data

Hora inici


05.060

22/06/2011

12:00

Exercici 3: Diagrama de casos d’ús (25%) Es vol elaborar un diagrama de casos d’ús que representi el funcionament parcial d’un taller de vehicles, sota els següents supòsits. Al taller hi treballen operaris de dos tipus, de “Xapa i Pintura” i de “Mecànica”. El Cap de Taller (que és també un operari), té com a missió la recepció dels vehicles, i l’assignació de la reparació a l’operari corresponent, depenent de la reparació que es necessita, de “Xapa i Pintura” o de “Mecànica”. A més, podrà fer la petició de material si cal. Un cop feta una reparació, l’operari que la tenia assignada accedeix al sistema i la tanca. Quan un client truca al taller per a consultar l’estat de la reparació del seu vehicle ha de parlar amb la secretària, que consulta la reparació i informa al client del seu estat. Tant en la recepció del vehicle com en el tancament de la reparació i en la consulta de l’estat cal cercar el vehicle.

Pàgina 4 de 6


Codi

Data

Hora inici


05.060

22/06/2011

12:00

Exercici 4: Diagrama de Seqüència (25%) Es vol elaborar un diagrama de seqüència que representi el procés iteratiu que permet tancar els expedients de casament d’un ajuntament o requerir-ne el pagament. El funcionari de l’ajuntament selecciona, d’entre tots els casaments que té assignats i que es mostren per pantalla, el que vol tractar. Un cop seleccionat, la pantalla invoca el controlador del sistema mitjançant una crida al mètode cercarCasament amb el codi del casament seleccionat i, a continuació, el controlador mostra per la pantalla la informació del casament en qüestió. Si el casament ja està pagat (el funcionari té la documentació en paper), el funcionari polsa damunt el botó corresponent en la pantalla i el controlador és informat amb el missatge tancarCasament. En rebre’l, tanca el casament i mostra la confirmació per la pantalla. D’altra banda, si el casament no està pagat, el funcionari polsa el botó de requerir pagament i la pantalla demana al controlador que reclami el pagament. El controlador invoca al mètode enviarMissatge del subsistema de missatgeria, indicant el codi del casament. Finalment la pantalla mostra un missatge de confirmació indicant que s’ha reclamat el pagament. Tant si el casament estava pagat com si no, un cop mostrat el missatge de confirmació, el funcionari polsa damunt el botó d’acceptar de la pantalla, que demana al controlador que tanqui l’expedient del casament. Llavors s’inicia el mateix procés per al següent casament, i es repeteix mentre existeixin casaments per tractar.

Pàgina 5 de 6


Codi

Data

Hora inici


05.060

22/06/2011

12:00

Exercici 5: Diagrama d’estats (15%) Es vol elaborar un diagrama d’estats sota el següent supòsit. En iniciar el sistema es produeix un esdeveniment inici que ens condueix a l’estat compost A, que conté dues seqüències de subestats. Una d’aquestes seqüències té com a primer subestat AA, del qual se surt en produir-se l’esdeveniment fiAA; aleshores s'invoca l’operació exeAA i així acaba aquesta seqüència. L’altra seqüència comença al subestat AB, del qual se surt quan a>b i es passa al subestat AC, del qual se surt en produir-se l’esdeveniment fiAC, amb el qual acaba aquesta altra seqüència; ara bé, si abans es produeix l’esdeveniment repetir i es compleix la condició noSortir, es torna a entrar al subestat AC. Quan se surt de l’estat A s’entra en dos estats simultanis, B i C. De l’estat B es passa a l’estat D després de 2 segons, i llavors s'executa el mètode fiB de l’objecte obj. De l’estat C es passa a l’estat D en produir-se l’esdeveniment fiC. Finalment se surt de l’estat D quan b>z, i així acaba tot el procés.

Pàgina 6 de 6

Ingeniería del software TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE OO

Tema 1

Introducción a la ingeniería del software orientado a objetos 1. Qué es la ingeniería del software 2. El ciclo de vida del software 3. Desarrollo estructurado y desarrollo orientado a objetos 4. Las herramientas CASE 5. El OMG y el UML

1. QUÉ ES LA INGENIERÍA DEL SOFTWARE Un software no es una obra de arte, sino un producto de consumo utilitario y masivo; sin embargo es un producto industrial con algunas características especiales: es un producto singular hay interesa copias dey software usados por millones de personas, la producción en (aunque serie no nos no suele ser algo excesivamente generalizado) y no se estropea con el paso del tiempo. La ingeniería del software comprende las técnicas, métodos y herramientas que se utilizan para producirlo. Hoy día la calidad del software y su productividad no han alcanzado un punto óptimo. Por ejemplo, no podemos probar un producto software frente a cualquier posible condición de utilización, lo cual va en contra de su calidad; y en cuanto a la productividad recalcar que cuando diseñamos un software, solemos partir de cero, no como cuando se diseña un coche, donde ya se tienen piezas perfectamente testadas y homologadas (tornillos, chapa, etc) que casi con seguridad sabemos no darán ningún tipo de error en el producto final. Actualmente ya se está intentando conseguir un cierto grado de reutilización de software con el diseño orientado a objetos. 2. EL CICLO DE VIDA DEL SOFTWARE

Ciclo de vida clásico

El ciclo vidadedelprogramación. software lo constituyen las ciclos etapasdeque las que siguen a la de etapa Existen varios vidapreceden, distintos,ycon etapas bien definidas, esto es así porque pretendemos cumplir los plazos dados, respetar los límites de los recursos asignados y también ofrecer calidad. 2.1. El ciclo de vida clásico

También denominado ciclo de vida en cascada, tiene las siguientes etapas:







 



Análisis previo: Se definen aquí los grandes rasgos del sistema de software

que tendrá que dar soporte informático a unas determinadas actividades. Deberá funcionar en un entorno hardware y red determinado que habrá que indicar; contaremos también con los recursos necesarios para el desarrollo y los condicionamientos temporales. El documento resultante de este análisis es la especificación del sistema y sirve de base para la siguiente etapa. Análisis de requisitos: Definiremos aquí con detalle las necesidades de información que tendrá que resolver el software, sin tener en cuenta por el momento, los medios técnicos. Deberemos requerir de los futuros usuarios las funciones y requisitos en general; y con esta información redactaremos la especificación de requisitos, con la suficiente precisión para que se pueda desarrollar y servir de base para un contrato entre el equipo de desarrollo del software y sus futuros usuarios. Diseño: El diseño especifica la solución a cada uno de los requisitos de la fase anterior. Con ello recogemos el documento especificación de diseño, que será la base para la programación. Programación: Traducimos a código el diseño de la fase anterior. Prueba: Testeamos el software desde distintos puntos de vista tratando de localizar y corregir en el software y en la documentación todos los posibles errores. Mantenimiento: o explotación del software, constantes actualización para mejorar la eficiencia o añadir funciones. Este proceso puede durar hasta 10

2 · Ingeniería del software

años o más, por lo que el coste de esta fase suele ser de 2 a 5 veces mayor que el coste de desarrollo. No obstante, este ciclo ha sido muy criticado porque tiene diferentes inconvenientes; el principal es que los requisitos iniciales que recogemos en el análisis de requisitos muchas veces no son fiables o son incompletos. Es muy difícil encontrar un conjunto de futuros usuarios que conozcan el entorno del software y que sepan exactamente qué es lo que quieres que haga el software. Así que una vez terminada oficialmente la fase de análisis y comenzada la de diseño, seguirán surgiendo nuevos requisitos y cambios; con lo que el software y la documentación pierden validez. Por ello, se han definido otros tipos diferentes de ciclo de vida. 2.2. El ciclo de vida con prototipos

Consiste en un software provisional que prioriza la facilidad y rapidez en la modificación sobre la funcionalidad; solo sirve para que los usuarios puedan ver cómo sería el contenido y el posible funcionamiento y apariencia del software, sin realizar realmente estas funciones. Así por comparación, los futuros usuarios podrán definir más exactamente qué es lo que quieren; y por supuesto se puede volver a fabricar otro prototipo y otro más hasta afinar exactamente en el resultado que buscamos. 2.3. La programación exploratoria

Se elabora una primera versión del software o de una parte de éste, se le enseña a los futuros usuarios para que la critiquen y se hacen los cambios que estos sugieran, esto se repetirá tantas veces como sea necesario. La diferencia con los prototipos es que en la programación exploratoria, el programa sí funciona y no es un mero prototipo (viene a ser lo que realiza Microsoft con sus betatesters, usuarios a los que les ofrece el programa para que busquen errores y modificaciones, antes de sacarlo a la venta comercialmente en una versión definitiva). 2.4. El ciclo de vida del Rational Unified Process  

 

Distingue 4 etapas: Inicio: Se establece la justificación económica y el alcance del proyecto. Elaboración: Se estudia el alcance del software, a quién debe dar cobertura y se realiza una planificación del proyecto. Construcción: Se desarrolla todo el proyecto de forma iterativa e incremental. Transición: Se entrega el producto al cliente y comprende todo el comienzo de su utilización , realizando los cambios necesarios y oportunos.

3. DESARROLLO ESTRUCTURADO Y DESARROLLO ORIENTADO A OBJETOS Los métodos estructurados provienen de la programación estructurada (C, C++), mientras que los métodos orientados a objetos provienen de la programación orientada a objetos (Java). Hay dos características del desarrollo orientado a objetos que han favorecido su expansión: por un lado permite por vez de software primera la lareutilización conel loprimer que mejoramos productividad y calidad a la de quemanera hacíamossignificativa, referencia en punto de este tema; y por otro lado se facilita la ayuda al desarrollo sobre todo por la notación orientada a objetos UML mayoritariamente aceptada.

4. LAS HERRAMIENTAS CASE CASE significa Computer-Aided Software Engineering. Son, por tanto, software de apoyo al desarrollo, mantenimiento y documentación informatizados del software. Se excluyen como herramientas CASE aquellas que no tienen solo finalidad (procesadores de texto, hojas de cálculo… que si bien necesitamos, no

podemos considerar CASE) o las que se utilizan para codificar software. Así

Ingeniería del software · 3

incluimos en las herramientas CASE las herramientas diagramáticas (a través del dibujo reconocen una clase, y no un simple rectángulo gráfico), las herramientas de gestión de la prueba y de la calidad y la de gestión de cambios. La expansión de las herramientas CASE se vio bastante frenada en su día debido a la disparidad y diversidad (no estandarización) de las técnicas que se utilizaban; con el diseño orientado a objetos hemos vuelto a la estandarización estas herramientas se expanden rápidamente. 5. EL OMG Y EL UML El OMG (Object Management se creóla en 1989 paradefomentar el uso de la tecnología orientada a objetosGroup) e impulsar generación este tipo de software; es una organización no lucrativa y está constituida por más de 800 empresas. El UML (Unified Modeling Language) es un modelo para la construcción de software orientado a objetos, que ha sido propuesto como estándar de ISO por el OMG. Con él se ha llegado aun modelo orientado a objetos único de forma oficial, pero eso no quiere decir que todo el proceso en todos los ingenieros sean únicos. De momento se ha conseguido que haya unos diagramas que todos los desarrolladores entenderán y harán de la misma manera; lo cual supone un importante avance, pero no es definitivo.


TEMA 2 UML1: El modelo estático

1. CONCEPTO DE MODELO ESTÁTICO Y DIAGRAMA DE CLASES El modelo estático del UML es aquél en el que se describen las clases y los objetos. Se denomina estático porque muestra todas las relaciones posibles a lo largo del tiempo, no las que son válidas en un cierto momento. El modelo estático consta de los dos diagramas siguientes: Diagrama de clases: Que puede contener clases y objetos y relaciones entre

Tema 2

UML1: El modelo estático 1. Concepto de modelo estático y diagrama de clases 2. Clasificadores y paquetes 3. Clase y conceptos afines 4. Relaciones entre clases 5. Comentarios y restricciones





estos, en y que se hace siempre. Este diagrama muestra la estructura estática de clases un dominio. Diagrama de objetos: Que solo contiene objetos y relaciones entre éstos, y es opcional.

El modelo estático pretende ser independiente del lenguaje de programación, por lo que será responsabilidad del diseñador del software evitar caer en la utilización de conceptos no soportados por el lenguaje de programación. 2. CLASIFICADORES Y PAQUETES El clasificador es la entidad básica del modelo estático. Un clasificador es más general que una clase. El clasificador en sí mismo no tiene símbolo gráfico, sino que lo tienen sus estereotipos; clases, tipos de datos, interfaz. La utilidad de este clasificador radica en el hecho de que los estereotipos mencionados tienen mucho en común, por lo que es suficiente con realizar la indicación una vez en el clasificador. La notación gráfica es la misma para todos: un rectángulo. Todos los

Ejemplo de clase e interfaz

clasificadores deben tener un nombre. En un clasificador se puede indicar la palabra clave “estereotipo” entre comillas latinas; cuando no se indique ningún estereotipo, se tratará de una clase. Un paquete es solo una caja que contiene elementos, que pueden ser clasificadores, objetos, u otros paquetes… Se representa como se observa en la figura lateral. Las relaciones que se pueden dar entre paquetes son: De especialización: si un paquete hereda de otro, el primero tiene elementos más restrictivos del segundo. De inclusión: Todos los elementos de un paquete están contenido en otro (éste además puede tener muchos más paquetes). De importación: Desde el paquete que importa, se reconocen los nombres de los elementos del otro paquete visibles desde el exterior. De acceso: No solo se reconocen los nombres como antes, sino que además se pueden utilizar. 







3. CLASE Y CONCEPTOS AFINES Una clase describe un conjunto de objetos en el que todos tienen los mismos atributos y operaciones. Cuando esa “clase” se palpa, se instancia, tenemos un objeto individual. La representación de una clase es más compleja que la de un clasificador, dado que consiste en un encapsulado de atributos y operaciones, daremos una representación gráfica más detallada que un simple rectángulo. Consistirá pues en un rectángulo con 3 compartimentos. En el primero estará el nombre de la clase, en el segundo la lista de atributos y en el tercero los servicios de la clase. Compartimento del nombre: Se puede indicar en la parte superior un estereotipo y justo debajo el nombre de la clase; se recomienda que se use un 

Dos formas de r epresentar un mismo paquete




sustantivo singular que a veces puede tener una segunda palabra que la califique y también se recomienda que empiece por mayúscula, podemos encontrar debajo del nombre comentarios optativos entre llaves denominados cadenas de caracteres de propiedades o valores etiquetados, si hay puntos suspensivos detrás implican que hay más elementos que no se ven. En el ejemplo lateral, el estereotipo análisis tiene una clase rectángulo, que se ha identificado en la etapa de análisis y tiene más etiquetas que no alcanzamos a ver. Compartimento de los atributos: Cada atributo de la clase tiene varios aspectos a tratar, por orden en su especificación son: Visibilidad: Indica hasta qué punto las operaciones de otras clases pueden (+), acceder al atributo, los símbolos quedelpodemos encontrar son: público protegido (#), privado (-) y dentro paquete (~). Nombre: Se recomienda que empiece por mayúscula, si es derivado (es decir, redundante con otros a partir de los cuales se puede obtener el valor), el nombre tiene que ir precedido de /. Expresión del tipo: real, entero, string… Valor inicial si lo tuviera Property string igual que en el nombre de la clase. Compartimiento de las operaciones : Tiene a su vez también varios aspectos a tratar:

Especificación de una clase



Visibilidad Nombre: Se recomienda que empiece por minúscula. Lista de parámetros: se compone de parámetros separados por

comas, y a su vez, cada parámetro se define con el tipo (in, out o inout; o el tipo de retorno cuando devuelva un valor como resultado), la expresión del tipo y el valor por omisión La herencia en el análisis y el diseño Herencia por especialización

La herencia existen dos comprende clases, de las unadees los la superclase y la otra presupone la subclase.queEsta subclase un cuales conjunto objetos de la superclase con todos los atributos y operaciones de instancia de la superclase y además, puede tener algunos específicos de la subclase. La herencia puede suceder por: Herencia por especialización : Se crea una subclase más especializada y restrictiva a partir de la superclase definida con anterioridad. Es ejemplo de ello 

la subclase “suite” de la superclase “habitación”; una suite es obviamente una

Herencia por generalización



habitación, pero tiene características específicas de espacio, decoración, tamaño. En cambio no todas las habitaciones son suites. La suite (subclase) es más restrictiva y menos generalizada que la habitación (superclase). Herencia por generalización: A partir de varias subclases, se encuentra una superclase que, solo se puede instanciar por medio de las subclases que la constituyen. Por ejemplo, en un municipio a la hora de recaudar se dan cuenta que las motos y ciclomotores cumplen prácticamente las mismas características salvo alguna diferencia. A partir de las dos se crea la superclase Vehiculosde2ruedas, que se subdivide en motos o ciclomotores. Todos los vehículos de dos ruedas o son motos o ciclomotores, nunca ambos (disjoint) y clase abstracta de la cual no se así vehiculosde2ruedas se directamente convierte en una pueden crear (instanciar) objetos, sino que se tienen que crear necesariamente en alguna de sus subclases. Se indica una clase abstracta bien poniendo su nombre en cursiva o bien con la propiedad {abstract} en el compartimento del nombre. Una clase abstracta puede tener operaciones abstractas que son las que solo están implementada en las subclases, en principio, en forma diferente en cada una.

Variantes en el concepto de clase Encontramos clases diferidas que con clases abstractas que tienen alguna operación abstracta; clases terminales, de las que no pueden colgar ninguna

subclase, no nos suele interesar que herede ninguna otra clase de ellas por varios motivos; metaclases, son clases cuyas instancias son a su vez, también clases y


no objetos; clases parametrizadas o también llamadas plantillas es un descriptor de clase frmalmente igual a una clase excepto que algún término de su definición es un parámetro. Cuando se dan valores a todos los parámetros de una plantilla, se obtiene una clase totalmente especificada; clases de utilidad son aquellas que incluyen rutinas y datos que no corresponden a ninguna clase u operación (por ejemplo parámetros del sistema que sólo pueden tener un valor cada uno), estas clases de utilidad no tendrán objetos. Interfaces

Una interfaz describe un conjunto de operaciones visibles de una clase, sin indicar su implementación. Se dice que dicha clase en cuestión implementa la interfaz; una una clase, diferidas. pero equivale unainterfaces clase abstracta sin atributos y coninterfaz todas no susesoperaciones Puedea las estableces relaciones de herencia entre sí, pero no pueden participar en asociaciones ni tener estados. La notación de la interfaz es como la de la clase, pero con el estereotipo interfaz y sin el compartimento de atributos, porque no los tiene. Instanciación

Representación de los objetos

Un objeto se representa gráficamente de una manera muy parecida a las clases: se indican los valores en los atributos de instancia y, opcionalmente, un nombre en el objeto, el nombre de la clase, todo subrayado. Se suelen omitir el tipo de los atributos, así como el compartimento de las operaciones, dado que ya se conocen gracias a la especificación de la clase. 4. RELACIONES ENTRE CLASES    

Las relaciones entre clases que vamos a estudiar son las siguientes: Asociaciones: binarias, reflexivas, n-arias. Clases asociativas: asociaciones calificadas, alternativas y derivadas. Agregaciones y composiciones: agregaciones, composiciones. Relaciones de dependencia

Asociaciones

Hay una asociación entre clases cuando una clase necesita otra u otras para la implementación de sus operaciones, lo cual se cumple por medio del paso de mensaje entre estas. Cada papel que se establece en esta Asociaciones asociación tiene asociada una cardinalidad. Estudiamos los Asociación binaria diferentes tipos: Asociaciones binarias: Son las que tienen lugar entre dos clases; como podemos observar en el ejemplo lateral observamos que una empresa se relaciona con las personas cuando son sus empleados. La flecha abierta implica que podemos navegar por los empleados a partir de la Asociación reflexiva 





empresa. La cardinalidad nos indica quedeunatener persona puede estar en 0 o en 10..1empresa (nada dos trabajos) y 1..* implica que toda empresa, al menos tiene un empleado. Asociaciones r eflexivas: Es un tipo especial de relación binaria en la que la clase se relaciona consigo misma. En el ejemplo lateral vemos que un trabajador a la vez puede ser jefe y subordinado. En este caso puedo tener cualquier número de subordinados, incluso 0 (*) y cada trabajador puede tener un jefe o ninguno (0..1). Asociaciones n-arias: Son aquellas en las que se relacionan n números de clases. Para facilitarlo, estudiaremos las ternarias. En el ejemplo lateral

Asociación ternaria

Interfaz Comparable


observamos como un autocar y un chofer pueden realizar múltiples excursiones o ninguna; pero en una excursión en concreto contamos con un único autocar y un único chofer.

Clases asociativas

Asociaciones calificadas

Clases asociativas

En principio, una asociación no es una clase; pero si ésta tiene que tener atributos y operaciones propias, entonces debe definirse como clase; y encontramos los siguientes tipos: Asociaciones calificadas: Se establece una asociación calificada mediante un atributo de una clase. Veámoslo con un ejemplo. En el ejemplo lateral observamos que en cada departamento y para cada 

Asociaciones alternativas



Asociaciones derivadas



categoría 0). laboral, haber categorizar un número como cualquiera de empleados (incluído Esto puede lo podemos el ejemplo inferior. Del atributo categoría de la clase departamento, pende la relación con el número de empleados. Asociaciones alternativas: Cuando una clase participa en dos asociaciones o más, pero cada objeto concreto solo puede pertenecer a una de ellas, hablamos de asociaciones alternativas (disjoint) y la forma de representarlo lo tenemos en el ejemplo lateral. Asociaciones derivadas: Es una asociación redundante que se puede obtener como combinación de otras relaciones del modelo. En el ejemplo, los alumnos matriculados de un curso concreto, los obtenemos por redundancia y por ello se pondría / que es el indicador de elemento derivado.

Agregaciones y Composiciones Agregaciones: Es un caso particular de asociación binaria en la que uno de los papeles tiene el significado de “parte” y otro el de “todo”. Pueden tener 

Clases asociativas

Agregaciones

Composiciones



diferentes significados: acoplamiento-piezas (unacontinente-contenido máquina y sus piezas, circuito eléctrico y sus componentes); (aviónuny los pasajeros, el avión seguirá siéndolo aunque no contenga pasajeros); colectivo-miembros (como el caso del equipo de fútbol que vemos en el ejemplo lateral). Un objeto puede tener diferentes componentes y éstos se señalan con un rombo hueco. En el ejemplo, observamos como un equipo de fútbol está formado por 1 portero, 3 defensas, 2 medios y 5 delanteros; se entiende que cada delantero es intercambiable. A su vez, un jugador puede estar en 1 equipo de fútbol o en ninguno (se acabó el fatigarse jugando en varios equipos de forma simultánea). Composiciones: En una composición, los objetos componentes no tienen vida propia, sino que cuando se destruye el objeto compuesto del que forman parte, también se destruyen ellos. Un objeto componente solo puede formar parte de un objeto compuesto y no puede pasar de un objeto compuesto a otro. Por ejemplo, un centro universitario pertenece a una universidad (y solo a una); en caso de que esta Universidad cierre, el centro universitario también lo hará, no podrá pasar a depender de otra. Las composiciones se representan con un rombo opaco.

Relaciones de dependencia

En esta relación, un elemento del modelo (cliente) depende para su implementación o funcionamiento de otro elemento (suministrador). El símbolo de una relación de dependencia es una flecha de línea discontinua y punta abierta. 5. COMENTARIOS Y RESTRICCIONES

8 · Ingeniería del software Comentario

Los comentarios en los modelos UML se ponen dentro de un rectángulo, con un vértice doblado enlazado con una línea discontinua al elemento al que se refiere ese comentario. Las restricciones expresan condiciones que debe cumplir el elemento del modelo al que se asocian, se representan igual que los comentarios, pero entre llaves {}, de modo que puedan ser interpretadas por las herramientas CASE. Como ya sabemos de otras asignaturas, en la programación por contrato hay 3 tipos de restricciones: 

 

Precondiciones de una operación.: Son restricciones que deben cumplirse antes de la ejecución Postcondiciones: Deben cumplirse al acabar la ejecución de una operación. Invariantes: Deben cumplirse en todo momento.


TEMA 3 UML2: EL MODELO DINÁMICO Y DE IMPLEMENTACIÓN

Tema 3

UML2: El modelo dinámico y de implementación 1. El diagrama de estados 2. El diagrama de casos de uso 3. Los diagramas de interacción 4. El diagrama de actividades 5. Los diagramas de implementación

1. EL DIAGRAMA DE ESTADOS Hay objetos cuyo comportamiento puede variar a lo largo del tiempo; cada una de estas variaciones son estados y son muy importantes en determinadas aplicaciones, como pueden ser las de tiempo real. En el diagrama de estados distinguimos los siguientes conceptos: 











Estado : Esnouna situación determinada de lasino vidaque de dependerá un objeto; de esoque sí, un estado corresponde a un instante dentro de tiempo,

se cumpla alguna condición o se produzca un acontecimiento. Transición simple: Consiste en que el objeto para de un estado (srcen) a otro (destino), que podría incluso ser el mismo. Esta transición comienza cuando se produce un acontecimiento determinado y, a la vez, se cumple una condición específica (condición de guarda). Transición interna: Son pseudotransiciones en las que no hay cambios de estado; se usan para especificar acciones que se deben ejecutar en respuesta a acontecimientos que no provocan cambios de estado. Acción: Es un proceso atómico, es decir, que o no se ejecuta o se ejecuta hasta el final. Acontecimiento: Son hechos que pueden provocar transiciones de un estado a otro. Encontramos los acontecimientos de llamada (cuando se llama una operación del objeto al que corresponde el diagrama), de señal (recepción de una señal por un objeto), de cambio (notificación de que una condición ha llegado a ser cierta) y de tiempo (o ha pasado un período de tiempo o que es una hora determinada). Acontecimiento interno: Son pseudoacontecimientos que están ligados a un estado en lugar de a una transición. Hay tres tipos: de entrada (Se producen

cuando el objeto entra en el estado correspondiente y tienen como nombre la palabra clave entry), de salida (Se producen a la salida del estado, su palabra clave es exit) y de acción (especifican acciones que se ejecutan cuando se llega al estado en cuestión y acaban por sí mismas o cuando se sale del estado) Las transiciones se representan mediante flechas de punta coloreada que van del estado de salida al de llegada. Con la flecha se encuentra una expresión que presenta la siguiente sintaxis: Signatura [ guarda ] / acción ^ envío

La signatura normalmente tiene un formato que reúne el nombre del acontecimiento y entre paréntesis los parámetros con su nombre y su expresión. Tipos especiales de acontecimientos son aquellos que son de tiempo –after()- o – when ()-. La guarda es una expresión que puede tomar el valor verdadero o falso. La acción se especifica en pseudocódigo y deberá incluir la Diagrama de estado

clave defer como primera si el acontecimiento es diferido. El envío presenta la acción siguiente forma: destino.mensaje (argumentos). Así, en el diagrama lateral, observamos que una factura que llega, si es aceptada, pasará al estado aceptada y de él, se procederá a su pago. En cambio, si da algún tipo de error (no especificado), pasará a un estado devolución, en el que permanecerá hasta que pasen 3 días y entonces se procederá a borrar la factura en cuestión.


Pueden existir transiciones complejas dado que un Transiciones complejas objeto o interacción puede estar en más de un estado al mismo tiempo, y pueden haber transiciones que salgan de más de uno o que vayan a parar a más de uno. Suele realizar funciones de sincronización. Se representan con barras cortas y gruesas de las que salen o a las que llegan los diferentes estados. Así, en el ejemplo lateral vemos que cuando llega una factura, pasamos a poner en pendiente lo que llega y lo que se pidió. Se comparan estos dos ítems (V1 y V2) y si se aceptan, la factura será pagada. Estados compuestos

compuesto Un estado es aquella en lapuede que existen subestados, cada uno de los cuales, a su vez, ser un estado compuesto. Un estado compuesto está representado por al menos, dos compartimentos separados por una línea; en la parte superior el nombre, y abajo el que contiene su diagrama de subestados. Cada secuencia de subestados ocupará una franja horizontal separada de las adyacentes por una línea discontinua. Detalles de subestados: Un subestado inicial se representa con un círculo lleno y uno final con un círculo lleno envuelto en una circunferencia. Las transiciones entre subestados de la misma secuencia (misma franja horizontal) se representan igual que entre estados; en cambio entre distintas franjas se usan pseudoestados de sincronización, como se puede ver en el ejemplo entre ev5 y ev6. Además el asterisco nos indica que no hay límite de veces en que se puede producir este salto. Las transiciones que entran o salen del estado compuesto, considerado como una unidad, se consideran que si entran, tienen como estados destino todos los 







estados iniciales todas las secuencias; mientras que si finales sale, es transición tuviera de como estados de srcen todos los estados decomo todas silasla secuencias. Así al salir en Est3 el estado anterior es Sub3 y Sub4. Al entrar desde Est1 entra en SUB1 y SUB2. Hay transiciones que tienen como destino un indicador de historia de los estados (en el ejemplo desde EST1 se puede llegar a H*); indica que en una transición de regreso al estado compuesto se vuelve al mismo subestado del que salió la última vez que partió del estado compuesto. Del indicador de historia puede salir también una transición hacia un subestado que será el destino en caso que ninguna vez se haya estado anteriormente en el estado compuesto (en el ejemplo, se llegaría a SUB1).

2. EL DIAGRAMA DE CASOS DE USO Los diagramas de casos de uso sirven para mostrar las funciones de un software desde el punto de vista de sus interacciones con el exterior y sin entrar en muchos más detalles. Un actor es un conjunto de papeles de una entidad exterior en relaciónque el con el sistema software considerado, podemos decir actorsea es la visión el software tiene de una entidad exterior. Para quequeununactor considerado como tal, debe cumplir dos requisitos: Ser autónomo con respecto al software, es decir, que la actividad que desarrolla a partir de la información suministrada por el software no esté subordinada a la de este. Mantener relación directa con el software o con entidades exteriores que desempeñan tareas subordinadas a la actividad del software.. 



EL caso de uso es una documentación sobre una interacción entre el software y un actor o más, siendo esta interacción una función autónoma dentro del software. Las relaciones que se pueden establecer entre casos de uso son:




Relaciones de extensión: El caso de uso A extiende el B si dentro de B se ejecuta A cuando se cumple una condición determinada. Relaciones de inclusión: Un caso de uso A está incluido dentro de los casos de



uso B, C, etc… si es una parte de proceso común a todos estos. Relaciones de generalización/explotación: Un caso de uso A es una



especialización de otro B, si A realiza todo el proceso de B más algún proceso específico.

Ejemplo de casos de uso y actores

Tanto para los casos de uso como para los clasificadores, no se utiliza el símbolo de los clasificadores, sino símbolos especiales como los siguientes: 







Los casos de uso se presentan de trazo continuo. A veces todas lasmediante elipses seelipses agrupan dentro de un gran rectángulo que representa todo el software. Los actores se presentan mediante una figura humana. Las relaciones de especialización entre actores y entra casos de uso se presentan igual que en las clases. Las relaciones de extensión e inclusión se representan mediante las palabras clave extend e include, respectivamente.

3. LOS DIAGRAMAS DE INTERACCIÓN Un diagrama de interacción sirve para describir el funcionamiento de los casos de uso y de operaciones complejas. Para ello, debemos estudiar las interacciones y colaboraciones y los diferentes diagramas que entre ellos se pueden dar. Una interacción es la especificación del comportamiento de un caso de uso y operación en términos de secuencias de intercambio de mensajes entre objetos. Estos mensajes contienen estímulos que pueden ser peticiones de ejecución de operaciones o señales. En cuanto a las colaboraciones hay que tener claro primero que es necesario que haya cierta coherencia entre el diagrama estático, para que el diagrama de colaboraciones pueda funcionar. Es decir, las clases y los clasificadores deben formar una correcta infraestructura. Una colaboración es un conjunto de papeles de clasificadores o instancias y de papeles de asociaciones entre aquellos que intervienen en una interacción. La representación gráfica de los papeles es igual que la de los clasificadores y asociaciones correspondientes, aunque solo es necesario especificar los elementos que están modificados en la colaboración. Los multiobjetos representan un conjunto de objetos de un papel con cardinalidad mayor que 1 dentro de una asociación; se representan por dos

Ejemplo de colaboración

rectángulos necesitan dos seleccionar mensajes para realizar una operación casa uno desuperpuestos sus objetos: yuno sirve para el conjunto de enlaces de en la asociación que corresponden a los objetos; y el otro mensaje se envía separadamente a cada objeto individual por medio del enlace respectivo; a veces estos dos mensajes se combinan dentro de uno. En la figura lateral observamos un ejemplo de colaboración y debajo el diagrama estático de partida. Se ha definido una colaboración entre un objeto y un multiobjeto y el papel que desempeña el objeto unLector se le ha dado el nombre prestatario, mientras que ni el multiobjeto de la clase Libro ni su papel tienen nombre.


El diagrama de colaboración es la representación de una interacción mediante un diagrama estático de la colaboración correspondiente sobre la cual se representan los mensajes de interacción. Para cada mensaje hay una especificación que debe contener: Predecesores: es la lista de los mensajes predecesores de dicho mensaje. El número de secuencia del mensaje que pone en funcionamiento toda la 

interacción es 1, a partir de ahí tenemos 1.1., 1.2…. mientras que si el mensaje



1.2. activa un proceso que envía a la vez dos mensajes, uno será 1.2a y otro 1.2b. Guarda: Es la condición que se tiene que cumplir para que se envíe dicho mensaje.





Expresión decondición secuencia . Cláusula de : Acostumbra a servir para definir ramas de ejecución. Valores de retorno: Especifica una lista de nombres de valores retornados (si



los hay) como resultado del proceso puesto en marcha por el mensaje. Signatura: Nombre del estímulo y lista de argumentos entre paréntesis.



A su vez los mensajes pueden ser asíncronos, que es cuando la clase emisora envía un mensaje y se continúa ejecutando sin esperar a que llegue el resultado y se representa por una flecha de punta abierta; o pueden ser síncronos, en los que hay que esperar que el suministrador acepte la respueste y se representa por una flecha de punta coloreada. Ejemplo de diagrama de colaboración En el ejemplo lateral se ha descrito una interacción en la que un bibliotecario pide información sobre un objeto de la clase Lector (identificado por su carnet) y sus préstamos mediante un mensaje al objeto unLector que solo tiene el número de secuencia y la firma de la operación pedida. Durante su ejecución unLector envía un mensaje al multiobjeto de la clase Libro siendo este último mensaje sincrónico. El diagrama de secuencias no representa explícitamente los papeles de asociaciones y se representan explícitamente el orden en el tiempo e incluso la duración de los mensajes y de las operaciones que se ponen en marcha. Se representa en dos dimensiones, con el tiempo se representa verticalmente y corre hacia abajo y en dirección horizontal tenemos los sucesivos papeles de clasificadores que participan en la interacción separados pro franjas verticales discontinuas; así queda representado de cada papel su línea de vida en un cierto período de tiempo. Si su destrucción está prevista al final, se indicará marcando con una X. Las activaciones son una parte de la línea de vida durante la cual dicho papel ejecuta una acción u otros papeles ejecutan otras acciones, como consecuencia de una acción ejecutada por el papel. Las Ejemplo de diagrama de secuencias activaciones se representan mediante rectángulos alargados verticalmente cuyo inicio y final coinciden con la llegada del mensaje que pone en marcha la acción y el envío del mensaje de respuesta, respectivamente. En los mensajes no se indican los números de secuencia, ya que quedan implícitos en el orden temporal los de mensajes; sí se pueden indicar mensajes de retorno aldefinal una activación en forma de los flechas de línea discontínua y punta abierta. En el ejemplo lateral se observa el diagrama de secuencias correspondiente al ejemplo de colaboración que habíamos visto anteriormente. 4. EL DIAGRAMA DE ACTIVIDADES Se puede considerar que es una variante tanto del diagrama de estados como el de interacción, ya que sirve para describir los estados de una actividad. Los elementos específicos que se encuentran en este diagrama son:




Ejemplo de diagrama de actividades

Estados de acción: No hay aquí objetos que esperan a que se produzcan

acontecimientos, sino objetos que están desarrollando una acción. Cuando acabe esta acción se producirá la transición, lo cual indica que un estado de acción no puede tener acciones ligadas a otros acontecimientos que no sean el de entrada ni tampoco tienen transiciones internas. Se representan como rectángulos pero con los lados laterales en forma de medio círculo. Flujos de objetos: Un objeto es creado o cambia de estado en una acción y es utilizado por otra u otras. Se representan mediante flechas de punta abierta y línea discontinua, 









como podemos ver en imagen: lateral. Estados de flujo delaobjeto Se representa con un flujo de objeto que entra y otro que sale y el símbolo del objeto en un estado es el mismo utilizado en las colaboraciones (rectángulo); incluso un objeto puede figurar varias veces en un diagrama, cada vez en un estado diferente. Estados de subactividad: Corresponden a todo un subdiagrama de subactividades y se representan como un estado de acción en cuyo interior hay pequeños estados de acción con transiciones entre ellos. Swimlanes: Franjas verticales del diagrama que corresponden a unidades organizativas responsables de diferentes acciones (en el ejemplo está el departamento peticionario, el control de gestión, etc.).

Iconos : Representan el envío de unaPuede señal alhaber acabar un estado dey acción ydesucontrol recepción en otro como entrada. bifurcaciones reunificaciones basadas en condiciones de guarda incompatibles (a menudo complementarias) por lo que no expresan sincronización, ya que los dos flujos de control son alternativos. Se suelen poner rombos en estos iconos de control, como vemos en la unidad organizativo control de gestión, en el ejemplo.

5. LOS DIAGRAMAS DE IMPLEMENTACIÓN Los diagramas de implementación no describen la funcionalidad del software como hemos visto hasta ahora, sino una estructura general con vistas a su contrucción, ejecución e instalación, y son dos distintos: el diagrama de componentes y el diagrama de despliegue. El diagrama de componentes describe la descomposición física del sistema software en componentes a efectos de su construcción y mantenimiento. Los componentes de los que se compone (valga la redundancia) identifican objetos Diagrama de componentes

físicos que tiempo de compilación desarrollo, tienen que unahay interfaz propia dey ejecución, bien definida. Pueden sero de códigos fuentey ejecutables, DLL, imágenes, incluso documentos manuales. Como vemos en la imagen lateral los componentes se representan mediante tres rectángulos, uno contiene el identificador del componente y dos menores incrustados en el lado izquierdo del primero. Las relaciones que se pueden dar entre componentes son en tiempo de desarrollo (asociaciones de componentes que modelan dependencias que se tendrán en cuenta en tiempo de compilación o enlace) o relaciones de llamada (asociaciones que sirven para modelar llamadas entre componentes. Además también un componente puede tener relaciones de agregación y composición, esto último reflejado en el ejemplo en el que el componente 2 contiene al componente 3.


El diagrama de despliegue permite mostrar la arquitectura en tiempo de ejecución del sistema respecto a hardware y software. Se utiliza en el diseño y la implementación y se distinguen en él componentes Ejemplo de diagrama de despliegue (como en el diagrama de componentes anterior) y nodos, así como relaciones entre estos. Es más limitado que el diagrama de componentes pues solo representa la estructura del sistema en tiempo de ejecución pero no en tiempo de desarrollo o compilación, pero en su parece es más amplio pues puede contener más clases de elementos. Los nodos representan objetos físicos existentes en tiempo de ejecución y modelan recursos que tienen y capacidad de proceso, pueden ser tanto ordenadores comomemoria dispositivos o actores. Se representan los nodos mediante paralelepípedos rectangulares, como vemos en el ejemplo lateral. Se establecen entre nodos relaciones mediante líneas continuas que significa que existe comunicación entre ellos. Un componente u objeto se podrá ejecutar si se utilizan los recursos de un nodo o puede estar contenido en éste.


TEMA 4 RECOGIDA Y DOCUMENTACIÓN DE REQUISITOS

Tema 4

Recogida y documentación de requisitos 1.Los requisitos y las fuentes de información 2. Pasos de la recogida y documentación de requisitos 3. La recogida y documentación de requisitos de la interfaz de usuario

1. LOS REQUISITOS Y LAS FUENTES DE INFORMACIÓN Los requisitos son la especificación de lo que debe hacer el software, son descripciones del comportamiento, propiedades y restricciones del software que debemos desarrollar. El papel de los requisitos es el de servir de base para un acuerdo entre los usuarios y los desarrolladores del software (en este sentido debe estar realizado de una manera inteligible para los usuarios que deben revisarlo) y además sonentrada la información de partida pie que da a la siguiente etapa.para desarrollar el software, es decir, son el Hay dos clases de requisitos: Los requisitos funcionales describen qué debe realizar el software para sus usuarios, mientras que los no funcionales no van asociados a casos de uso en concreto y son restricciones impuestas por el entorno y la tecnología. Las fuentes de información a las que debemos recurrir para recoger la información sobre los requisitos son: Entrevistas y eventualmente encuestas a los futuros usuarios, si además podemos observarles directamente en su puesto de trabajo, mucho mejor. Documentación sobre el sistema actual existente, y si está informatizado también echaremos mano de los manuales y procedimientos. Colegas de los usuarios para conocer el mismo trabajo desde otros puntos de vista. Revisión de sistemas parecidos dado que el usuario no mencionará funciones importantes del software que para él no son visibles o no le da la 







debida importancia. 2. PASOS DE LA RECOGIDA Y DOCUMENTACIÓN DE REQUISITOS Conocemos Los siguientes pasos: 1. El contexto del software: Se trata de recoger los requisitos conociendo e indagando en la actividad profesional de los usuarios. Informáticamente sabemos trabajar, pero no conocemos el entorno organizativo que nos piden para ese software. A su vez existen dos modelos para describir este contexto. El modelo del dominio es la más simplificada y recoge los tipos de objetos más importantes para establecer una clasificación. Un modelo más complejo es el modelo de negocio que describe los procesos y entidades principales entorno al software. En éste último modelo se profundiza identificando todos los casos de uso, las entidades que participan en él…

2. Los guiones: Se denomina así a lo que los usuarios conocerán como casos de uso, es decir, identifican de manera organizativa lo que quieren que haga el software; son una fuente de información muy importante, ya que expresan las necesidades de los usuarios tal como ellos las ven. 3. Identificación de los actores : Distinguimos principalmente el usuario final (colectivo o personas que interactuarán directamente con el sistema), el usuario privilegiado (o gestor del sistema, encargado de definirla forma de funcionamiento del sistema) y el entorno informático (interfaz no humana del software). 4. Identificación de los casos de uso : Se obtienen a partir de los guiones, y son procesos autónomos iniciados por un actor o por otro caso de uso. 5. Identificación de las relaciones entre casos de uso : Ya sabemos que hay 3 tipos de relaciones principales: las relaciones de extensión (siempre se relacionan con una condición, como pueden ser diferentes flujos de proceso o casos especiales o errores que debemos tratar); las relaciones de inclusión (es


un recurso para evitar la descripción de una misma parte del proceso dentro de diferentes casos de uso); y la relación de especialización (un caso de uso es versión especializada de la otra). 6. Identificación de las relaciones de especialización entre actores : El actor A e suna especialización del B si A tiene todos los apeles de B y alguno más. Esto no suele representar problemas para identificarlo. 7. Documentación de los casos de uso: Encontramos dos tipos de documentación: la textual y la formal. En la documentación textual encontramos la descripción textual donde aparece el nombre de los actores, otra terminología que se pueda usar con ellos y referencias a otros casos; y también contiene un glosario, muy conveniente para unificar terminología y su documentación formal interpretación. Por otro de latolostambién que consiste en un diagrama casos deestá usolaque muestre todas las relaciones posibles entre éstos y entre los actores; pero no entramos en demasiada profundidad, es decir, solo los utilizamos como función complementaria y no se elaboran sistemáticamente para todos los casos de uso. Más adelante, utilizaremos los diagramas de análisis en esta fase de análisis con mayor profundidad.

3. LA RECOGIDA Y DOCUMENTACIÓN DE REQUISITOS DE LA INTERFAZ USUARIO La interfaz de usuario es lo que los usuarios ven del funcionamiento del software. También se denomina interfaz hombre-máquina y de ella dependen varios factores: La comodidad del usuario en cuanto a ansiedad, frustración, fatiga. Productividad del usuario: ergonomía en cuanto a la hora de seleccionar menos teclas y botones. Imagen del software: El usuario suele juzgar la calidad del software sólo por la  



imagen de éste, y nunca se cuenta la calidad de la programación. No se puede diseñar correctamente una interfaz de usuario sin saber para quién se diseña y hay que evitar el error de diseñar la interfaz para uno mismo, dado que la cultura profesional y los conocimientos informáticos no van a ser los mismos en nuestro caso que en los usuarios reales del software. Para ello es fundamental documentar las tareas de los usuarios: es decir, que tareas hacen y con qué frecuencia, el entorno en que se lleva a cabo (limitaciones de espacio, iluminación…), su situación dentro del flujo de tareas, qué documentos y

herramientas son necesarios, identificar los problemas y errores más frecuentes. Por último, las especificaciones de usabilidad son los requisitos no funcionales relativos a la interfaz de usuario, y se pueden referir a la facilidad de utilización o aprendizaje o a rapidez y precisión en la ejecución de las tareas, conviene expresarlas en forma cuantitativa, como por ejemplo, que el 90% de los usuarios tras una semana de aprendizaje, puedan registrar una media de diez facturas en 30 minutos o menos.


TEMA 5 ANÁLISIS ORIENTADO A OBJETOS

Tema 5

Introducción a la ingeniería del software orientado a objetos 1. El papel del análisis 2. Paquetes de análisis, y de servicios y revisión casos de uso 3. Especificación de las clases de análisis 4. Especificación formal de los casos de uso y análisis de la interfaz de usuario.

1. EL PAPEL DEL ANÁLISIS 

 

El análisis tiene 3 principales cometidos: Traducir los requisitos a un lenguaje más formal. En la etapa anterior de recogida de documentación y requisitos se han descrito las funciones del software en forma de casos de uso y de tareas, ahora bien, un desarrollo posterior orientado a objetos debe utilizar un formalismo de clases y objetos que todavíalasnoclases tenemos. Identificar fundamentales para la implementación del software. Expresar los casos de uso en términos de clases.

Existe un alto grado de continuidad entre el análisis y la etapa posterior de diseño, tal es así que probablemente la mayoría de las clases identificadas en la etapa de análisis serán ya definitivas en el diseño posterior. La utilidad del análisis por lo tanto es fundamental pues se puede analizar todo el software con un coste relativamente bajo; hay veces que no se desarrolla un modelo de análisis, es decir, de los requisitos se pasa directamente al diseño, pero solo es recomendable en casos extremadamente sencillos. 2. PAQUETES DE ANÁLISIS Y DE SERVICIOS Y REVISIÓN CASOS DE USO Por sencillo que sea un proyecto de software, es conveniente dividir la documentación en paquetes de UML. Cada paquete debe ser coherente (los elementos que constituyen el paquete deben estar fuertemente relacionados) y poco dependiente conexiones entre diferentes). su vez este paquete (pocas de análisis se divide enelementos paquetes de de paquetes servicio, es decir, porA su funcionalidad y cada paquete de servicio sólo puede estar en un paquete de análisis a la vez. Los paquetes de análisis corresponden cada uno de ellos a uno o varios subsistemas enteros y pueden servir para repartir el trabajo del análisis entre varias personas o equipos. Normalmente, los casos de uso entre los que hay relaciones de extensión, inclusión o generalización deben asignarse al mismo paquete. Los paquetes de servicios son subdivisiones de los paquetes de análisis desde un punto de vista que podríamos llamar comercial. Comprenden normalmente casos de uso relacionados y habitualmente tienen que ver con un único actor o, en cualquier caso, con pocos; son indivisibles (o un cliente tiene un paquete de servicios completo, o no lo tiene).

Hay veces que es necesaria una revisión de los casos de uso , especialmente si en la fase anterior solo se implementaron estos casos de uso para servir de acuerdo entre usuarios y desarrolladores. Si no se han estudiado a fondo estos casos, puede ocurrir que haya dos casos que realicen funciones parecidas quizá de forma contradictoria. 3. ESPECIFICACIÓN DE LAS CLASES DE ANÁLISIS 

Se consideran tres tipos de clases de análisis: Clases de frontera: Representan en el nivel de análisis la interfaz de usuario

por pantalla. Debe haber al menos una para cada papel de cada actor y representan objetos gráficos complejos como ventanas, diálogos de pantalla, menús… Si modificamos en el futuro la forma de presentar en pantalla los






datos pero sin afectar al proceso de los mismos, solo habremos de cambiar las clases frontera. Clases de entidades: Corresponden a los objetos del dominio que formalmente serán persistentes, es decir, durarán más que el proceso que los crea. Clases de control: Corresponde a objetos internos del software, no persistentes, no modelan nada del mundo real y sus operaciones suelen contener la parte principal de los algoritmos de aplicación. Si en el futuro tenemos que variar los algoritmos de proceso sin cambiar nada en los datos, solo será necesario modificar las clases de control.

las clases Uno de los hacerlo problemas que se da esporque el identificar es importante correctamente la mayoría pasarándea entidades la fase de, diseño, existen algunas formas de identificarlas, pero no hay una regla maestra, por ejemplo: bibliotecas de clases ya definidas y programadas que además podremos reutilizar; clases sugeridas por los expertos en el dominio, la documentación revisada de los casos de uso…

Normalmente rechazaremos las clases sin atributos, las que no tengan operaciones, las que solo tengan un atributo (ya que pueden ser realmente el atributo de otra) y las clases con un solo objeto. La especificación de los atributos de las clases de entidades es una tarea más sencilla, pues suelen ser datos mencionados explícitamente en los casos de uso. EL modelo de análisis conviene que sea independiente del lenguaje de programación, así que los tipos de atributos serán abstractos (no por ejemplo entero) ni asociados a un lenguaje en concreto; asimismo el nombre de los atributos puede ser libre, pero conviene que tenga un formato compatible con la mayoría de lenguajes de programación. Como casos especiales de atributos encontramos los quenotienen un valor compartido pordevarios objetos (atributos de clase); los atributos aplicables a todos los objetos la clase (entonces es mejor crear una superclase con estos atributos aplicables y luego una subclase más restringida); y atributos con valores repetidos (a veces mejor los definimos como una clase aparte con una asociación n a 1 con al primera). Llegados a este punto, tenemos una lista, en principio completa, aunque provisional de las clases de software y conviene ahora examinar las relaciones de herencia, asociaciones y relaciones de agregación que pudiésemos encontrar: 

Jerarquías de herencia : Vamos a encontrar dos, la especialización y la generalización. En la especialización solo añadiremos subclases si sus

atributos tendrán atributos, operaciones o asociaciones que no tendrá el resto de los objetos de la superclase. En la generalización hay más puntos a tener en cuenta: Si diferentes clases de significado parecido tienen atributos y operaciones comunes, podremos definir una superclase común que agrupe a estas subclases, los atributos eso sí deben estar definidos iguales, pero las operaciones solo deben tener el nombre en común (la superclase será 





abstracta); que una superclase abstracta tenga sólo una subclase, enno estetiene casosentido suprimiremos la superclase. Herencia múltiple: Cuando una clase hereda de diferentes superclases, tiene atributos, operaciones, asociaciones y agregaciones de todas éstas. Puede haber conflicto dado que para un mismo atributo o propiedad con el mismo nombre no sabemos que superclase prevalece e incluso existen lenguajes que no soportan la herencia múltiple, aunque esto último no es motivo para renunciar a ella en esta fase de análisis. Interfaces: Recordemos que son clases abstractas sin atributos y con todas las operaciones abstractas, y pueden ser una buena alternativa a las clases abstractas, ya que son más flexibles. Asociaciones: Existirá asociación entre clases cuando los objetos de una necesitan la colaboración de objetos de otra para llevar a cabo sus operaciones.

Clases de análisis: frontera, control y entidad




Por ello hay asociaciones entre clases de frontera y al menos algunas clases de control, por una lado, y entre clases de entidades por otro. Conviene una clase asociativa cuando la asociación tiene atributos o bien hay una clase cuya vida de los objetos está relacionada con la de los enlaces de la asociación y solo tiene un objeto para cada enlace. Además conviene revisar casa asociación con cardinalidad múltiple en los dos papeles para determinar si no debería ser en realidad una clase asociativa. Agregaciones: Son un caso particular de asociación, en el que un papel es parte del otro en algún sentido. La identificación de las clases de frontera, control y operaciones salen

la descripción textual delaslosclases casosdedecontrol, uso. Más directamente lo hacenveces las clases de frontera, más indirecta y las entidades muchas están implícitas pero suelen ser bastante obvias. 4. ESPECIFICACIÓN DE CASOS DE USO Y ANÁLISIS INTERFAZ DE USUARIO. Hasta aquí, hemos descrito la estructura estática del software que se desarrolla, a través de la descripción formal de los casos de uso. Pero la forma simplificada que hemos utilizado no tiene en cuenta la secuencia de los mensajes, ni el hecho de que puedan ser repetidos un cierto número de veces o que estén sujetos a diferentes condiciones. Para algunos casos sencillos lo anterior puede ser suficiente, pero en otras ocasiones será necesario realizar un diagrama de secuencia o de colaboración completos, o, a veces, diagramas de actividades. El análisis de la interfaz de usuario parte de la información siguiente:   

Documentación de las tareas futuras. Especificaciones usabilidad. Lista de las clasesdefrontera

Y su principal objetivo es un esquema del contenido de cada ventana asociada a una clase de frontera, excepto las ventanas secundarias, que solo sirven para aspectos como presentar mensajes al usuario o pedirle confirmaciones.


TEMA 6 DISEÑO ORIENTADO A OBJETOS

1. EL PAPEL DEL DISEÑO Recordemos que siguiendo el ciclo de vida del Rational Unified Process, el análisis y el diseño constituyen un único componente de proceso, pero nosotros los consideraremos dos etapas diferentes porque tienen una finalidad distinta y porque el resultado también es claramente diferente. La etapa del diseño hace de puente entre el análisis yla realización. El modelo del describe las funciones tienesiguientes que desempeñar software (plantea el análisis problema) mientras que las que etapas deben elbuscar las soluciones a esas especificaciones. Hemos visto que en proyectos muy sencillos se puede llegar a prescindir del análisis. En cambio, el diseño es siempre necesario. 2. LA REUTILIZACIÓN La reutilización es fundamental en el diseño del software y por sí misma, es ya motivo más que suficiente para justificar la existencia de esta fase. Encontramos que con una buena reutilización conseguimos varias ventajas: 







Se abrevia el desarrollo del software, disminuye el trabajo de mantenimiento y mejoramos la fiabilidad. El código reutilizado suele ser más eficiente porque se ha ido mejorando con el tiempo. Se gana en coherencia: dado que se suelen reutilizar varias clases y por ello suelen estar programadas de la misma mismo más estilo.difícil que se Si se reutiliza un buen fragmento de forma código,y con seráelmucho pierda ya que habrá muchas más copias.

La reutilización tiene 4 modalidades: la de clases, de componentes, los patrones y los marcos. La reutilización de clases suele acontener cuando éstas son independientes del dominio como interfaces gráficas y estructuras de datos generales. La reutilización de componentes requiere primero saber qué es un componente: Es un conjunto de clases cuyos objetos colaboran en tiempo de ejecución con el fin de llevar a cabo una función concreta. Dado que un componente implementa una interfaz determinada (todas las operaciones de sus clases que se pueden pedir del exterior) se puede sustituir un componente por otro que implemente la misma interfaz. Los patrones son una manera organizada de recoger la experiencia de los diseñadores de software para volverla a utilizar en casos parecidos. Cuando un experto informático inventa una solución, rara vez la invención es completamente suya, sino que adapta parte de una solución que ya existía. Esto son los patrones, no son en sí programas sino ideas de diseño extraidas de la experiencia que constituyen un esbozo de solución o receta para problemas parecidos que pueden aparecer con frecuencia, y que solo debemos adaptar a nuestro caso particular. Así la reutilización avanza un paso más; en casos determinados en los que no se puede reutilizar código, al menos se puede reutilizar el diseño, como mínimo, las ideas básicas. Ya existen “recetarios” de patrones preexistentes que, además, van

aumentando con el uso de sí mismos, así encontramos que patrones nuevos ya hacen referencia a patrones existentes anteriormente a ellos.  

Las características de los patrones son: Recogen la experiencia, es decir, no se inventan completamente de nuevo. Son algo más amplio que una clase u objeto.

Tema 6

Diseño orientado a objetos 1. El papel del diseño 2. La reutilización 3. El diseño arquitectónico 4. El diseño de los casos de uso 5. Revisión del diagrama estático del diseño 6. Diseño de la persistencia 7. Diseño de la interfaz gráfica 8. Diseñodel de usuario los subsistemas










Crean vocabulario: dentro de un diseño se hará referencia a los patrones por su nombre; por ello el nombre que le asignemos al patrón y por el cual se conocerá no debe ser trivial. Son un instrumento de documentación, ya que hacer referencia un patrón dentro de nuestra documentación nos ahorrará describirlo enteramente. Dan una solución genérica a un caso concreto, que nosotros debemos completar. Los componentes de los patrones son: Nombre: Ya vimos que no es trivial, en los patrones no puede haber sinónimos o alias.



 

Contexto : El entorno dentro del cual se presenta el problema que es resuelto por el patrón. Problema: Requisitos que la solución debe cumplir. Solución: El patrón.

Los patrones, a menudo, hacen referencia a otros patrones, ya sea porque los utilizan o porque los complementan. Cuando utilizamos un sistema de patrones (bastante frecuente) hay que documentar las relaciones entre éstos y la descripción de las dependencias entre ellos cuando se utilizan juntos. Los marcos de aplicaciones son un conjunto de clases que constituyen una aplicación incompleta y genérica. Si el marco se complementa de manera adecuada (se especializa) se obtienen aplicaciones especializadas de un cierto tipo. Hay dos tipos de marcos: Marcos de caja blanca: Con un conjunto de clases de las cuales está definida la interfaz y la implementación. Para especializarlo hay que implementar las subclases de estas clases. Marcos de caja negra: Tienen definidas unas interfaces denominadas papeles, y 



para especializarlo hay que añadirles clases que implementen sus papeles. Los marcos tienen varias ventajas: Reducen el trabajo al programar, dado que aplicamos subsistemas que sabemos que funcionan y por ello el código no se deberá sobrescribir ni mantener; llevan a desarrollar pequeñas aplicaciones que encajan dentro de los marcos, en lugar de aplicaciones monolíticas; los marcos permiten que otras compañías puedan suministrar componentes que los desarrolladores podrán añadir. Pero a su vez, también encontramos inconvenientes: Limitan la flexibilidad pues los componentes para un marco deben amoldarse a las restricciones impuestas por la arquitectura de éste; tienen un aprendizaje difícil, como media se requieren 3 semanas para estudiarlo a fondo, aunque ciertamente solo se debe realizar una vez y puede servir este aprendizaje para muchas aplicaciones que se basen en este marco estudiado; reducen el grado de creatividad de los desarrolladores. Aunque los marcos y los patrones pudieran parecernos lo mismo, son bastante diferentes: Los patrones son soluciones más pequeñas que un marco: un marco puede 

 

contener varios pero no al revés. Los patrones sonpatrones, más abstractos. Los patrones son menos especializados, ya que se pueden utilizar en cualquier tipo de aplicación.

3. EL DISEÑO ARQUITECTÓNICO El diseño arquitectónico tiene como objetivo definir las grandes líneas del modelo del diseño; y comprende las actividades siguientes: 

Establecimiento de la configuración de la red : Es decir, determinar los nodos y sus características, las conexiones entre ellos, ancho de banda…




Establecimiento de los subsistemas: Pueden ser subsistemas propios o

desarrollados por otras compañías o incluso software de mercado. Podemos también aplicar patrones arquitectónicos y generalmente aplicaremos la división de paquetes realizada en la etapa de análisis. Las dependencias entre subsistemas serán como mínimo, las dependencias que ya existen entre los paquetes de análisis y los paquetes de servicios correspondientes. 4. EL DISEÑO DE LOS CASOS DE USO El diseño de la implementación de los casos de uso parte del diagrama de colaboración resumido que se hadehecho en la yetapa de análisis, y se consideran por separado las clases de frontera, entidades de control. Las clases de frontera son el punto de partida del diseño de la interfaz de usuario. Las clases de control y de entidades sirven para implementar la funcionalidad de los casos de uso. Debemos intentar aprovechar la oportunidad de reutilizar componentes y aplicar patrones y marcos siempre que sea posible. El proceso de diseño de las clases de control comienza con el estudio de la implementación de las operaciones ya identificadas en el análisis, una por una. A menudo necesitaremos nuevas operaciones de clases para implementar éstas o incluso clases nuevas. Después habrá que estudiar la implementación de estas nuevas operaciones. Con las nuevas clases y operaciones llegamos al diagrama estático de diseño. 5. REVISIÓN DEL DIAGRAMA ESTÁTICO DE DISEÑO Generalmente el diagrama estático de diseño se va haciendo a la par que se losobtenido. casos de La uso,revisión y una vez acabado ello, debemos revisión del diseñan diagrama del diagrama obtenido (quehacer sueleuna contener 5 veces más clases que el diagrama de análisis) se basa en: 

Normalización de los nombres: Por continuidad será bueno utilizar la misma

terminología del diagrama estático del análisis. Aunque es posible que debamos cambiar algunos nombres bien porque vulnerar alguna norma aplicable al proyecto, bien para respetar una terminología ya establecida en proyectos anteriores o bien porque el lenguaje de programación no lo soporta (esto último debíamos haberlo previsto con anterioridad. 

Reutilización de las clases: Durante el diseño las clases se hacen a medida,

ahora se trata de revisarlas sistemáticamente en busca de clases que pueden ser reutilizadas por otras ya existentes. 

Adaptación de la herencia en el nivel soportado por el lenguaje de programación: La herencia múltiple no suele ser soportada por todos los lenguajes. Por ello existen varias formas de deshacerla: por duplicación

consistente en duplicar en la subclase los atributos que heredaría de una de las superclases; por delegación, manteniendo una sola de las superclases e incluyendo dentro de la subclase una referencia a un objeto de la otra superclase, que tiene el valor de los atributos correspondientes; por interfaces, sustituyendo la herencia doble por herencia simple más una interfaz implementada por otra superclase; o por agregación, como podemos observar en la imagen de la página siguiente. 

Sustitución de las interfaces : Si el lenguaje de programación no soporta las

interfaces, las sustituiremos por clases abstractas. 

Cambios para la mejora del rendimiento: Ahora en el diseño nos debemos

preocupar por cuestiones de eficiencia que en el diseño no nos preocupaban.

Ingeniería del software · 23 Supresión de la herencia múltiple



Agrupación de clases para reducir el tránsito de mensajes:

Antes habíamos sustituido los atributos con valores múltiples por una clase aparte que comparta con la primera una asociación de n a 1; pues bien, quizá ahora nos interese el cambio a la inversa, ya que así no hay que enviar un mensaje de una clase a otra. 

Especificación de : operaciones implícitas

las En general para toda clase debe haber una operación que la instancia, otra que destruya objetos y operaciones que lean y pongan los valores de todos los atributos. 

Referencias a las clases frontera: Hay que sustituir las

operaciones de las clases de frontera por operaciones en elementos de la interfaz de usuario. 

Cohesión y acoplamiento : Ya

estamos casi seguro de tener un diagrama estático con todas las clases que deberá tener para sus implementaciones, y con todas bien; definidas. Puesatributos es ahoray cuando hay que revisarlo para sus que operaciones sea coherente es decir, los operaciones de cada clase deben tener mucha relación entre sí, hasta el punto de considerarla una unidad. Las clases y operaciones poco coherentes son más difíciles de entender, presuponen relacionar varias entidades en relación de 1 a 1, y se ven afectadas por más modificaciones. El acoplamiento también es importante y expresa el grado en el que éstos dependen de otras clases y objetos para llevar a cabo su responsabilidad; es mejor un menor acoplamiento, dado que cuanto más tenga una clase, más se vera afectada por cambios en otras y por tanto, se deberá modificar más a menudo. 6. DISEÑO DE LA PERSISTENCIA Se llama clases persistentes a las que pueden tener objetos persistentes, y clases temporales a las no persistentes. Un objeto persistente es aquel que tiene una vida más larga que el proceso que lo crea, o dicho de otra forma, un objeto se crea en un proceso y se utiliza en procesos posteriores, por lo que hay que grabarlo en sistema de tres almacenamiento permanente y también lógicamente debe poder ser un leído. Existen tipos principales de sistemas de almacenamiento: bases de datos orientadas a objetos, bases de datos relacionales y ficheros clásicos; y base de datos object-relacional. Bases de datos orientadas a objetos

Como es lógico suponer es el caso más sencillo de todos, ya que no hay que transformar los objetos para hacerlos persistentes. Solo hay que enriquecer la definición de la clase con objetos persistentes, indicando cuales de sus atributos lo son y qué política de lectura de objetos se requiere: todos de una vez, o leer según demanda). Bases de datos relacionales y ficheros clásicos


Aquí la cuestión ya se complica un poco: a un objeto le corresponde en principio, una fila de una tabla de base de datos relacional o un registro de un fichero; y a los atributos le corresponden columnas de la tabla correspondiente. Se hace necesario realizar la transformación anterior antes de grabar un objeto y hay que llevar a cabo la inversa antes de poderlo utilizar para ser leído. Existen tres formas de llevar a cabo la gestión de la persistencia: 





Cada clase persistente tiene operaciones para que los objetos se graben, borren, etc, por sí mismos. Es la opción más eficiente dado que requiere menos llamadas a objetos, pero dependerá de cada gestión de base de datos concreta y, por tanto, no es unacada solución a otroEste sistema distinto. Gestor de disco para claseportable persistente: gestor accede directamente en cada clase al fichero o base de datos, así la clase de entidades se desacopla del sistema de gestión de base de datos y además el gestor puede servir de memoria caché intermedia. Esta solución es menos eficiente que la anterior. Mezcla de las dos anteriores: se crean gestores de disco y se añaden operación de grabación, lectura en cada clase de dominio. Se diferencia del primer método en que puede ser más portable, sobre todo si implementamos la persistencia por medio de un marco. En cualquiera de los casos debemos pasar por 4 fases para definir la

Supresión de la herencia

estructura de base de datos relacional o con ficheros clásicos:

1. Transformamos el modelo estático en un modelo entidad-relación: se convierte cada clase con un atributo con valores múltiples en dos clases unidas por una asociación, y después le hacemos corresponder un tipo de entidad a cada clase no asociativa. Después se añade una relación para cada asociación con cardinalidades que son obvias. 2. Supresión de la herencia: Como el sistema de base de datos no soporta la herencia podemos resolverlo: a. Definiendo una tabla para cada clase que contendrá los atributos propios de la clase y los heredados. Es una solución sencilla pero tiene tantas tablas como subclases, hay que crear un gestor de disco para cada subclase, un cambio en la definición de “cliente” obligaría a cambiar todos los gestores de disco…

b. Se puede crear una tabla para la superclase en la que se graba a todos los clientes; a la vez se crea una tabla complementaria para cada subclase con el identificador del objeto y los atributos específicos (en este caso el descuento). Es buena solución si sólo una pequeña fracción de los objetos de la clase pertenecen a la subclase y además si los valores de los atributos son de longitud fija. c. Se crea una única tabla para todas las jerarquías de herencia con todos los campos, tanto de la superclase como de todas sus subclases y se le añade un campo que nos diga qué subclase del objeto corresponde a cada fila. La eficiencia en tiempo es muy elevada en esta solución, pero menos en ocupación de disco. El gestor de disco es una clase diferente de la clase persistente y, dentro de las operaciones de ésta, hay llamadas a operaciones del gestor de disco. Podemos considerar que todos los gestores de disco tienen al menos unas operaciones básicas: leer, grabar, regrabar y borrar. Por ello todos los gestores son subclases de una superclase GestorGenerico, en la cual las operaciones serían abstractas. El diseñar gestores de disco para la materialización según demanda (lectura según demanda) es más compleja y sólo se justifica cuando la materialización es costosa o cuando se debe poder sustituir la clase de entidad sin tener que modificar todas las que la utilizan. En resumen las referencias exteriores de estos gestores no se hacen a objetos de la clase de entidades en cuestión, sino

CASO A Tabla Cliente Nif: string, clave principal Nombre: String ….

Tabla ClienteEspecial NIF: String, clave principal Nombre: String Descuento: Integer CASO B Tabla Cliente Nif: string, clave principal Nombre: String ….

Tabla Auxiliar ClienteEspecial NIF: String, clave principal Descuento: Integer CASO C Tabla Cliente Nif: string, clave principal Tipo: Integer Nombre: String ….

Descuento: Integer …


a objetos de una clase sustituta. La clase srcinal y la sustituta implementan la misma interfaz. Bases de datos object-relational

Es el mismo diseño que las bases de datos relacionales, con la diferencia de que este nievo modelo puede tener atributos de tipo compuesto y, por tanto, no será necesario crear gestores de disco para todas las clases persistentes, sino sólo para aquellas a las cuales se accederá directamente.

7. DISEÑO DE LA INTERFAZ GRÁFICA DE USUARIO La interfaz gráfica de usuario (GUI) es solo una parte de la interfaz de usuario en general: es la interfaz implementada por medio de pantallas gráficas con teclado y ratón (no entran aquí por ejemplo los listados por impresora) y su diseño considera tres aspectos: 

 

El contenido: Establecido en los esquemas de las ventanas elaborados en el análisis. El formato: Que se especifica íntegramente en esta fase. La interacción: Es decir, la dinámica de la interfaz de usuario, denominada diálogo entre usuario y sistema.

En general, y para no extendernos demasiado, las características de un buen diseño son: 

 

  



Sensación de control: Los usuarios no quieren tener la sensación de ser controlados por el ordenador. Adecuación usuario y no a nosotros lo diseñamos. Familiaridadalpara el usuario; utilizandoque conceptos y organizaciones a los que suela estar acostumbrado. Flexibilidad: Interfaz adaptable a las preferencias del usuario. Atención a las posibilidades de errores del usuario. Robustez y sensación de seguridad: Se tiene que permitir que el usuario explore el producto sin riesgo de perder información o de perderse, permitiendo siempre deshacer la última acción. Facilidad de utilización y aprendizaje

8. DISEÑO DE LOS SUBSISTEMAS Habíamos definido con anterioridad subsistemas en el diseño arquitectónico y se habían especificado las interfaces respectivas y las dependencias entre éstas. Cuando ahora se acabe la fase de diseño, conviene llenar de contenido los subsistemas especificando qué clases comprende cada uno y haciendo explícitas las dependencias en el nivel de clase.


TEMA 7 INTRODUCCIÓN AL SOFTWARE DISTRIBUIDO

1. ENTORNOS DISTRIBUIDOS Y ENTORNOS ABIERTOS Se habla de entorno distribuido cuando el software de una aplicación se ejecuta repartido entre varios ordenadores de una red; entonces también decimos que el software en cuestión es distribuido. La razón decisiva para la evolución hacia los entornos distribuidos es que la misma capacidad de proceso resulta mucho más barata si se consigue con PC que con mainframes o máquinas Unix (incluso 5 veces más barato). Los objetivos que se persiguen con los entornos distribuidos son:  

 

  

Portabilidad de aplicaciones y de servicios del sistema Interoperabilidad: En diferentes ordenadores y aplicaciones podemos comunicarnos. Integración: Uniformidad. Transparencia: Los usuarios pueden leer datos de un ordenador sin saber dónde está y los procesos se pueden ejecutar en varios ordenadores sin que los usuarios sepan en cual de ellos. Facilidad de crecimiento del sistema. Compartimiento: Se pueden compartir recursos, servicios y aplicaciones. Seguridad: Los datos de un usuario están protegidos en lo que respecta a la consulta y actualización.

Un entorno abierto es un sistema distribuido en el que se intentan conseguir los objetivos de los sistemas distribuidos, y hacer que las interfaces entres sus componentes respeten un conjunto amplio y completo de normas sobre comunicaciones, programación, presentación e interfaces. 2. ENTORNOS CLIENTE/SERVIDOR CLÁSICOS La idea básica de la arquitectura cliente/servidor es que un programa (el servidor) gestiona un recurso compartido concreto y hace determinadas funciones sólo cuando las pide otro (el cliente) que es quien interactúa con el usuario. Normalmente los programas cliente y servidor se encuentran en ordenadores diferentes. Las ventajas que proporciona este modelo es que permite que la información se procese cerca de donde se ha generado, las funciones del software pueden quedar repartidas en varias máquinas, el crecimiento del hardware puede ser gradual y se facilita el uso de interfaces gráficas de usuario y aplicaciones multimedia. Los inconvenientes son que el servidor puede ser un cuello de botella, el software distribuido es más complejo y por tanto proporciona más errores y tiende a fallar más. Encontramos la arquitectura cliente/servidor de dos capas : 





Primera generación: Típico de redes de área local donde los clientes son PC

o estaciones de trabajo en los que se ejecutan las aplicaciones. Los servidores solo llevan a cabo funciones generales y de bajo nivel. Entornos de igual a igual: Un ordenador es el cliente para otras máquinas y el servidor para estas mismas u otras e incluso sí mismo. Segunda generación.

Las arquitecturas de dos capas presentan limitaciones al crecimiento del número de clientes ya que todos ellos deben conectarse al mismo servidor y es difícil mantener el software de los clientes, ya que cualquier cambio se debe hacer en todos al mismo tiempo.

Tema 7

Introducción al software distribuido 1. Entornos distribuidos y entornos abiertos 2. Entornos cliente/servidores clásicos 3. Entornos con middleware: CORBA 4. RMI 5. Documentos distribuidos:compuestos DCOM 6. Desarrollo del software distribuido


En la Arquitectura de tr es capas encontramos un servidor (primera capa) y un agente y un cliente (2ª y 3ª respectivamente). Los agentes intermediarios se encargan de traducir las aplicaciones, controlar la carga del servidor… 3. ENTORNOS MIDDLEVARE: CORBA Supresión de la herencia múltiple

Cuando la red aumenta todavía más sus dimensiones e incorpora multiplicidad de aplicaciones, plataformas y redes, es necesario un componente que gestione la comunicación entre todos estos elementos; este componente va colocado los clientes y los servidores y por este motivo entre se denomina software intermedio o middleware. El software distribuido puede llevarse a cabo con software clásico, pero si se hace con software orientado a objetos se dan mejores resultados dado que el paso de mensajes a un objeto que está en otro ordenador puede hacerse igual que si estuviera en el mismo. En CORBA hablaremos de interfaces, sabemos que en el software orientado a objetos y como consecuencia de la encapsulación, los objetos se comunican por medio de mensajes en los que se piden operaciones y valores de atributos y por ello distinguimos interfaces. El concepto de interfaz en CORBA es muy parecido al de UML ya que la misma organización ha especificado ambos. procesamiento de las peticiones según la imagen El lateral, tiene las siguientes fases: El cliente invoca la petición. Cuando llega al ORB (Object Request Broker), la demanda incluye una referencia al objeto que es su destinatario. El ORB utilizando el depósito de implementaciones, localiza el proceso del servidor o lo pone en funcionamiento si es necesario. El ORB localiza el POA (Portable Object Adapter) correspondiente al objeto destinatario de la demanda o bien pide su creación al activador del adaptador. Si no se consigue se recibirá la excepción object_not_exist. El POA localiza o activa el sirviente del objeto de formas distintas según las políticas vigentes. Se localiza el esqueleto y se hace la gestión de las respuestas y las excepciones.  







Los servicios de objetos que venimos a encontrar en un entorno CORBA son: 





Servicio de nombres: Gestiona estructuras de nombres de objetos que sirven para localizarlos desde otros objetos. Servicio de acontecimientos: Un acontecimiento es un hecho que guarda relación con un objeto y tiene interés para otros objetos, a los que se hace accesible mediante un mensaje denominado notificación. Este servicio gestiona este tipo de eventos. Servicio de notificaciones: Es una extensión del servicio anterior con funciones adicionales.










Servicio de relaciones: Permite crear relaciones, permanentes y temporales, entre dos o más objetos, sin modificarlos y sin que éstos lo sepan. El concepto de relación en este servicio es muy similar al de asociación en UML. Servicio de ciclo de vida: Proporciona operaciones para crear, copiar, mover y borrar objetos de forma local o remota; además soporta asociaciones entre grupos de objetos y condiciones de integridad referencial entre objetos. Servicio de propiedades: Sirve para definir atributos de los objetos dinámicamente. Servicio de tiempo: Se utiliza para obtener la hora, confirmar el orden en que se han producido diferentes acontecimientos y generar eventos relativos al tiempo.













Servicio de externalización: Sirve (internalizarlo). para convertir un objeto en un stream (externalizarlo) o justo lo congtrario Servicio de estados persistentes: Su función es guardar el estado de un objeto en memoria permanente y recuperarlo cuando sea necesario. Servicio de control de la concurrencia: Su finalidad es arbitrar los accesos concurrentes a un objeto con la intención de garantizar su integridad. Proporciona interfaces para que los clientes puedan reservar y liberar recursos para coordinarse en su uso compartido. Servicio de transacciones: Una transacción es una unidad de proceso que o bien llega a acabar normalmente o bien, en el caso de que se vean abortadas, las actualizaciones en bases de datos que hubiesen hecho se anulan, como si nunca hubiesen empezado. Servicio de seguridad: Mantiene la confidencialidad, integridad y disponibilidad de los datos mediante identificaciones por autenticación, control de acceso o auditoría de seguridad. Servicio de licencias: En el mundo de los objetos distribuidos podemos encontrar objetos de pago; entonces conviene que sea posible medir el uso de los objetos con vistas a una posterior facturación. El servicio de licencias da apoyo a esta función.

4. RMI RMI (Temote Method Invocation) es la herramienta de Java para el soporte de objetos distribuidos. RMI tiene una funcionalidad muy reducida en comparación con CORBA, pero en cambio presenta la ventaja de que las invocaciones remotas tienen lugar sin salir del entorno Java. 5. DOCUMENTOS COMPUESTOS DISTRIBUIDOS: DCOM Los documentos compuestos nos interesan porque dentro de una interfaz gráfica de usuario pueden figurar documentos considerados objetos, y porque los documentos compuestos pueden resultar de la combinación de documentos distribuidos y es entonces un caso particular de la tecnología de objetos distribuidos. Un documento compuesto es aquel documento que resulta de la agregación de otros (que además también pueden ser compuestos), que denominaremos componentes, dentro de un determinado documento marco. OLE es una ampliación del portapapeles y de DDE para crear documentos compuestos orientados a objetos. Se puede llevar a cabo la inclusión de documentos de dos formas: 

Embedding: Inclusión: Una copia del objeto y su formato de presentación se

almacenan dentro del documento y se transfieren con este.




Linking: Enlace: El documento que se incluye dentro del compuesto continúa

dentro de su ubicación srcinal en un documento exterior o dentro del mismo documento compuesto, y el objeto que lo representa en este último sólo contiene el formato y un puntero. Un documento compuesto de OLE contiene tantos datos propios como objetos gestionados por otras aplicaciones: típicamente le corresponde un fichero compuesto, y hace de intermediario entre dos tipos de componentes: los contenedores, que proporcionan lugares donde poner las cosas, y los servidores, que son las cosas que se ponen. Un tercer tipo de componentes de OLE son los OCX, que tienen un conjunto de interfaces predefinidas. 6. DESARROLLO DEL SOFTWARE DISTRIBUIDO El análisis de requisitos del software distribuido es el mismo que veníamos haciendo hasta ahora, dado que este análisis se ocupa de lo que le debe aparecer al usuario por las pantallas y por las impresoras, independientemente de que todo el proceso de haga localmente o no. La distribución de objetos también es similar a como la hacíamos hasta ahora, dado que están determinados por la funcionalidad.

Texto elaborado a partir de: Ingeniería del software

Benet Campderrich Falgueras, Recerca Informàtica, S.L.

Febrero 2004

RESUMEN INGENIERÍA DEL SOFTWARE 1er SEMESTRE 2008-09

UOC

TEMA – 1 INTRODUCCIÓN EL SOFTWARE Un sistema de software, también denominado aplicación o simplemente software, es un conjunto integrado de programas que en su forma definitiva se puede ejecutar, y que además comprende las estructuras de datos que usan dichos programas y la documentación.

EL SOFTWARE COMO PRODUCTO INDUSTRIAL El software es un es producto de consumo utilitario y masivo; para una empresa o trabajador autónomo, el software es un medio auxiliar que interviene de manera más o menos indirecta, pero a menudo imprescindible, en su gestión y cada vez más en su proceso productivo. El software no se estropea por el uso ni el paso del tiempo –si finalmente se tiene que sustituir es porque se ha quedado tecnológicamente anticuado o inadaptado a las nuevas necesidades o porque ha llegado a resultar demasiado caro mantenerlo.

LA INGENIERÍA DEL SOFTWARE La ingeniería del software comprende las técnicas, métodos y herramientas que se utilizan para producirlo. Existen dos grandes problemas de la ingeniería del software: la calidad y la productividad. El problema de la calidad es debido a la gran complejidad del software comparado con otros productos, que provoca que no sea posible probar el funcionamiento de un software en todas las combinaciones de condiciones que se pueden dar. En cuanto al problema de la productividad es debido a que, a diferencia de otras tecnologías, en un proyecto de software el desarrollo empieza tradicionalmente de cero. Uno de los grandes retos es conseguir desarrollar fragmentos de software (componentes) que sean reutilizables. También se consigue con patrones de diseño, y marcos o frameworks.

EL CICLO DE VIDA DEL SOFTWARE Está constituido por las etapas que preceden o siguen a la programación.

El ciclo de vida clásico o ciclo de vida en cascada:

Autor: Fistandantilus con la c olaboración indirecta de Ice y zumix Página 1 de 48


UOC

Análisis previo: y también análisis de sistemas o ingeniería de sistemas. En esta etapa se definen los grandes rasgos del sistema de software que tendrá que dar soporte informático a unas actividades determinadas de unos ciertos usuarios dentro del marco más general de la actividad de la empresa u organización.

Análisis de requisitos: o simplemente análisis. Su objetivo es definir con detalle las necesidades de información que tendrá que resolver el software, sin tener en cuenta, por el momento, los medios técnicos con los que se tendrá que llevar a término el desarrollo del software.

El diseño: es la etapa siguiente. Si el análisis especifica el problema o “qué tiene que hacer el software”, el diseño especifica una solución a este problema o “cómo el software tiene que hacer su función”.

La programación: o codificación, que es la cuarta etapa, consiste en traducir el diseño a código procesable por el ordenador.

La etapa de prueba: consiste en probar el software desde distintos puntos de vista de una manera planificada y, naturalmente, localizar y corregir dentro del software y su documentación los errores que se detecten.

El mantenimiento: o, si se prefiere, explotación, del software, ya que siempre que se utilice el software habrá que mantenerlo, es decir, hacer cambios –pequeños o grandes– para corregir errores, mejorar las funciones o la eficiencia, o adaptarlo a un nuevo hardware o a cambios en las necesidades de información. EL INCONVENIENTE DEL MODELO DE CICLO DE VIDA EN CASCADA ES QUE NO ES REALISTA.

a)

En primer lugar, es difícil encontrar un conjunto de futuros usuarios que conozcan

lo suficiente el entorno en el que se tiene que utilizar el software, que hayan reflexionado lo suficiente sobre lo que quieren conseguir y que, además, se pongan de acuerdo. b) En segundo lugar, porque el trabajo de consolidación de las peticiones de estos usuarios nunca será perfecto.



UOC

Por tanto, el modelo de ciclo de vida en cascada puede ser válido si se aplica de manera que cada etapa, del análisis de requisitos a la prueba, no prevea todo el conjunto del software, sino solo una parte cada vez; entonces tendríamos un ciclo de vida iterativo e incremental basado en el ciclo de vida en cascada. El ciclo de la vida en cascada ha sido muy criticado y se han propuesto algunos modelos alternativos.

El Ciclo De Vida Con Prototipos Para ayudar a concretar los requisitos, se puede recurrir a construir un prototipo del software. Un prototipo es un software provisional, construido con herramientas y técnicas que dan prioridad a la rapidez y a la facilidad de modificación antes que a la eficiencia en el funcionamiento, que sólo tiene que servir para que los usuarios puedan ver cómo sería el contenido o la apariencia de los resultados de algunas de las funciones del futuro software.

La Programación Exploratoria La programación exploratoria consiste en elaborar una primera versión del software, o de una parte de éste, enseñarla a los usuarios para que la critiquen y, a continuación, hacerle los cambios que éstos sugieran, proceso que se repetirá tantas veces como sea necesario. La diferencia principal con respecto a los prototipos es que aquí el software es real desde el principio. La programación exploratoria se puede considerar un ciclo de vida iterativo, pero no incremental, ya que el software está completo desde la primera versión. Como consecuencia de las numerosas modificaciones que sufre, la calidad del software desarrollado de esta manera y de su documentación tiende a ser deficiente, como la de un software que haya experimentado un mantenimiento largo e intenso.

El Ciclo De Vida Del Rational Unified Process Fases:

1) Inicio (inception), en la que se establece la justificación económica del software y se delimita el alcance del proyecto.

2) Elaboración, en la cual se estudia el dominio del problema, o simplemente dominio (parte de la actividad de la empresa dentro de la cual se utilizará el software ) y se tienen en cuenta muchas de las necesidades de información y eventuales requisitos no funcionales y restricciones, se establece la arquitectura general del software y se realiza una planificación del proyecto. 3) Construcción, en la que se desarrolla todo el producto de forma iterativa



UOC

e incremental, tiene en cuenta todas las necesidades de información que debe satisfacer y desarrolla la arquitectura obtenida en la fase anterior.

4) Transición, que comprende la entrega del producto al cliente y el comienzo de su utilización; aunque es posible que sea necesario hacer retoques en el software y añadir nuevas funciones como consecuencia de errores detectados o de requisitos que se habían pasado por alto hasta el momento. En cada una de estas fases se llevan a término (en diferentes proporciones) los siguientes proceso: capture), • Recogidacomponentes de requisitos de ( requirement • Análisis y diseño, • Realización (implementation), • Prueba (test). Cada unidad en la que se ejecutan pocos o muchos de los componentes de proceso es una iteración, y se aplica a un nuevo fragmento de software. Todas las fases tienen iteraciones.

DESARROLLO ESTRUCTURADO Y DESARROLLO ORIENTADO A OBJETOS Los métodos estructurados Los métodos estructurados provienen de la programación estructurada y se utilizan técnicas no muy integradas entre sí. La especificación de los procesos y la de las estructuras de datos generalmente quedan bastante diferenciadas, y hay métodos que ponen más énfasis en aquéllos o en éstos. Muchas de sus técnicas o bien pasan de lo general a lo particular (técnicas top-down) o bien a la inversa (técnicas bottom-up).

Los métodos orientados a objetos Los métodos orientados a objetos tienen sus raíces en la programación orientada a objetos. El diagrama básico de estos métodos, el tanto en el análisis como en el diseño.

diagrama de clases y objetos, puede servir

Hay dos características principales del desarrollo orientado a objetos: •

La reutilización del software

•

El desarrollo de herramientas informáticas de ayuda al desarrollo; este factor podría ser potenciado por el hecho de que en estos últimos años ha aparecido una notación orientada a objetos muy ampliamente aceptada, UML.



UOC

Los métodos formales Los denominados métodos formales parten de una especificación de las necesidades de información en términos de un modelo matemático riguroso, del cual se podría deducir el programa que les satisfaga; también permitían demostrar matemáticamente que un programa es correcto en el sentido de que se ajusta a aquellas necesidades.

LAS HERRAMIENTAS CASE CASE significa Computer-Aided Software Engineering. Las herramientas CASE son software de apoyo al desarrollo, mantenimiento y documentación informatizados de software. Ayudan a aplicar técnicas concretas de desarrollo y mantenimiento de software y por eso gestionan información sobre los elementos y conceptos que se utilizan en los métodos de desarrollo, como las siguientes: •

• •

Las herramientas diagramáticas, las cuales, a diferencia de las de dibujo, reconocen que un determinado símbolo es una clase y no simplemente un rectángulo. Estas herramientas también acostumbran a aceptar documentación textual sobre aquellos elementos. Las herramientas de gestión de la prueba y de gestión de la calidad en general. Las herramientas de gestión de cambios, etc.

EL OBJECT MANAGEMENT GROUP(OMG) El OMG es una organización no lucrativa en la que participan más de ochocientas grandes empresas de software, de hardware, usuarias y consultoras, y tiene la finalidad de fomentar el uso de tecnología de objetosportabilidad e impulsar la introducción de software orientado a objetos quelaofrezca reusabilidad, e interoperabilidad en entornos distribuidos heterogéneos.

UNIFIED MODELING LANGUAGE(UML) El UML es un modelo para la construcción de software orientado a objetos que ha sido propuesto como estándar de ISO por el OMG. Consta de un conjunto de tipos de diagramas interrelacionados, dentro de los cuales se utilizan elementos del modelo, que sirven para describir distintos aspectos de la estructura y la dinámica del software.



UOC

TEMA – 2 EL MODELO ESTÁTICO UML, TRES MODELOS DE DI AGRAMAS DIFERENTES: • •

•

El modelo estático, que describe la estructura de clases y objetos. Lo modelo dinámico o modelo de comportamiento, que describe las interacciones entre los objetos dentro del software. El modelo de implementación, que describe la estructura del software en términos de los componentes de que consta y su ubicación.

El modelo estático consta de los dos diagramas siguientes: •

•

El diagrama de clases, que puede contener clases y objetos y relaciones entre éstos, y que se hace siempre. El diagrama de objetos, que sólo contiene objetos y relaciones entre éstos, es opcional, ya que se utiliza principalmente para realizar ejemplos del diagrama de clases con objetos concretos de éstas.

El clasificador es la entidad básica del modelo estático. Un clasificador es más general que una clase; es un conjunto cuyos elementos se denominan instancias. El clasificador en sí mismo no tiene símbolo gráfico, sino que lo tienen sus estereotipos: clase, tipo de dato e interfaz. Una interfaz sólo describe las operaciones de una clase que son visibles desde otras clases; se dice que dicha clase implementa la interfaz correspondiente Todos los clasificadores deben tener un nombre. En un clasificador se puede indicar la palabra clave del estereotipo (entre comillas latinas, «»); cuando no se indique ningún estereotipo, se tratará de una clase.

CLASES: Puesto que una clase es un clasificador, se puede utilizar como símbolo de la clase un simple rectángulo con el nombre; sin embargo, dado que una clase consiste en un encapsulado de unos atributos y unas operaciones, también se da una representación



UOC

gráfica más detallada por medio de un rectángulo dividido en los tres compartimentos siguientes: • • •

El primer compartimento contiene el nombre de la clase. El segundo compartimento contiene la lista de los atributos. El tercer compartimento corresponde a los servicios de la clase.

El compartimento del nombre En la parte superior del compartimento de la clase se puede indicar un estereotipo*. Justo debajo se encuentra el nombre de la clase. Se recomienda que sea un sustantivo en singular que a veces puede tener una segunda palabra que la califique que a su vez se recomienda que comience por mayúscula.

Especificación de los atributos Cada atributo tiene un nombre o identificador y un tipo. Este último puede ser un tipo simple del lenguaje de programación como un entero o carácter, o bien un tipo complejo, como una lista de enteros, o también una clase ya definida. Se indica que un atributo es atributo de clase subrayando su definición. La visibilidad de un atributo indica hasta qué punto las operaciones de otras clases pueden acceder al atributo, y se indica mediante los siguientes símbolos: público: “+” (las operaciones de cualquier clase) • protegido: “#” (las operaciones solo de las clases herederas) • privado: “-” (solo sus propias operaciones) • También tienen visibilidad otros elementos del modelo estático, como las operaciones y los extremos de asociación. Se recomienda que comience por minúscula, y cuando se trate de un atributo derivado (es decir, que es redundante con otros a partir de los cuales se puede obtener el valor), el nombre tiene que ir precedido de “/”.



UOC

Especificación de las operaciones Una operación se define de la siguiente forma: visibilidad nombre ‘(’ lista-de-parámetros ‘):’ tipo-de-retorno ‘{’property string‘}’

Se indica que una operación es operación de clase subrayando su definición. La visibilidad se indica igual que en el caso de los atributos.

HERENCIA EN EL ANÁLISIS Y EL DISEÑO: La subclase comprende un subconjunto de los objetos de la superclase, los cuales, por tanto, tienen todos los atributos y operaciones de instancia de la superclase (se dice que la subclase los hereda) y, además, pueden tener algunos adicionales, específicos de la subclase.

Herencia por especialización Se llama de esta manera porque lo que se hace es crear una clase más especializada, más restrictiva, a partir de una clase definida con anterioridad.



UOC

Herencia por generalización. Clases abstractas En este caso se procede al revés: a partir de las subclases, se encuentra la superclase; este proceso se denomina generalización.

Una clase abstracta {abstract}, es una superclase de la cual no se pueden crear (instanciar) directamente objetos, sino que se tienen que crear necesariamente en alguna de sus subclases. Por esta razón se dice que las clases abstractas son no instanciables. Una clase abstracta puede tener operaciones abstractas, que son las que sólo están implementadas en las subclases, en principio, de forma diferente en cada una. Una operación y una clase abstractas deben de tener o bien su definición en cursiva, o bien la propiedad {abstract} al final. Las clases

diferidas son clases abstractas que además tienen alguna operación abstracta.

Las metaclases son clases cuyas instancias son clases (no objetos). En UML la metaclase es un estereotipo de la clase. Las interfaces describen un conjunto de operaciones visibles de una clase, sin indicar su implementación. Se dice que dicha clase en cuestión implementa (<>) la interfaz. Una interfaz no es una clase, pero equivale a una clase abstracta sin atributos y con todas sus operaciones diferidas. Las interfaces no pueden participar en asociaciones ni tener estados. Se dice que una clase utiliza una interfaz porque alguna de las operaciones de la clase llama a alguna de operación de la interfaz (<>):



UOC

RELACIONES ENTRE CLASES: Asociaciones Hay una asociación entre clases cuando una clase necesita otra u otras para la implementación de sus operaciones, lo cual se cumple por medio del paso de mensajes entre éstas. Dentro de una asociación, se considera que cada clase desempeña un papel (role) determinado; cada papel tiene asociada una cardinalidad. Entre las mismas clases puede haber asociaciones diferentes con significado diferente. Una asociación puede tener nombre, que sirve para identificar su significado, y también se puede dar un nombre a cada uno de los papeles/roles de las clases. Asociaciones binarias y n-arias:

Asociaciones binarias son las que tienen l ugar entre dos clases. Las dos clases pueden ser la misma (asociación reflexiva), y en este caso es posible permitir que un objeto esté enlazado consigo mismo o que no lo esté. Por ejemplo: Asociación binaria:



UOC

Asociación reflexiva:

Una relación ternaria es aquella que tiene tres papeles, es decir, participan tres clases, y en general una relación n-aria es la que tiene n papeles (n clases participan). Las relaciones no binarias, ya que no se pueden representar mediante una línea, se representan mediante un rombo:

Clases Asociativas:

En principio, una asociación no es una clase: no tiene por qué tener atributos ni operaciones, y puede carecer incluso de nombre. No obstante, si una asociación tiene que tener atributos y operaciones propias o bien una de las dos, entonces se debe definir como clase. En este caso se habla de clase asociativa. Una clase asociativa se representa como una clase colgada del símbolo de la asociación (la línea, en el caso de una asociación binaria, o el rombo en los otros casos) por medio de una línea discontinua:



UOC

Asociaciones alternativas:

Puede ocurrir que en una clase que participe en dos asociaciones, cada objeto concreto participe en una o en la otra, pero no en las dos. Entonces se habla de asociaciones

alternativas.

Asociaciones derivadas:

Agregaciones (es parte de) y composiciones (solo forma parte de) Agregaciones:

Una agregación es un caso particular de asociación binaria en la que uno de los papeles tiene el significado de ‘parte’ y el otro, el de ‘todo’, en algún sentido. Denominaremos componentes la clase correspondiente al primer papel y a sus objetos, y clase y objetos agregados, a los del segundo papel. Las agregaciones pueden tener diferentes significados: •

•

Acoplamiento-piezas: una máquina y sus piezas, un circuito eléctrico y sus componentes, un sistema de software y sus programas; cada parte tiene un papel concreto y no se puede cambiar por ninguna otra. Continente-contenido: un avión y los pasajeros que transporta, que no constituyen el avión, ya que un avión sin pasajeros es por sí solo un avión.


RESUMEN INGENIERÍA DEL SOFTWARE 1er SEMESTRE 2008-09 •

UOC

Colectivo-miembros: un grupo excursionista y sus excursionistas, o bien una promoción de alumnos y dichos alumnos; se supone que los miembros no tienen papeles diferenciados y, por tanto, son intercambiables.

La agregación se representa con un rombo vacío que parte del “todo”:

Composiciones:

La composición (o agregación de composición) es un caso particular de la agregación. En una composición, los objetos componentes no tienen vida propia sino que, cuando se destruye el objeto compuesto del que forman parte, también se destruyen. Además, un objeto componente sólo puede formar parte de un objeto compuesto y no puede pasar de un objeto compuesto a otro. Estas restricciones no existen en el caso de agregaciones en general. En una composición denominaremos la clase agregada clase compuesta, y el objeto agregado, objeto compuesto: La composición se representa con un rombo negro que parte del objeto compuesto:

Un centro universitario (facultad, etc.) pertenece a una sola universidad (de hecho, por la parte de la clase compuesta, la cardinalidad en una composición es siempre 1). Una universidad debe tener, al menos, un centro universitario. Suponemos que si desaparece una universidad desaparecen también sus centros universitarios, y que éstos no se trasladan de una universidad a otra.



UOC

COMENTARIOS Y RESTRICCIONES: Comentarios Un comentario se pone dentro de un rectángulo con un vértice doblado, enlazado con un línea discontinua al elemento al que se refiere.

Restricciones Las restricciones expresan condiciones que debe cumplir el elemento del m odelo al que se asocian. Se representan igual que los comentarios, salvo que van entre llaves {}, lo cual indica que pueden ser interpretadas por las herramientas CASE. Las especificaciones de UML incluyen un lenguaje para la descripción de las restricciones, denominado OCL, pero se puede utilizar UML sin usar este lenguaje. Las restricciones de las operaciones, o la programación por contrato son en UML de tres tipos: •

•

•

Precondiciones: son restricciones que se deben cumplir antes de ejecutar una operación; su cumplimiento nos garantiza que la operación se ejecuta partiendo de un estado correcto del sistema. Postcondiciones: se comprueban al acabar la ejecución de una operación, y garantizan que cuando esté terminada la operación, el sistema vuelva a situarse en un estado correcto. Invariantes: son condiciones que se deben cumplir en todo momento. Se tienen que comprobar al inicio (excepto los constructores) y al final de cualquier operación.

Se denominan también aserciones en el UML.

REPRESENTACIONES

LíneaPunta continua: triangular vacía: subclase de clase. Punta abierta: navegación por medio de una asociación o agregación. Sin punta: asociación.



UOC

Línea discontinua: Punta triangular vacía: la clase implementa la interfaz (<>). Punta abierta: una clase tiene relación de dependencia respecto a la otra (<>). Sin punta: conecta una clase asociativa con la asociación correspondiente (y también enlaza un comentario en el elemento del diagrama al que se aplica).

Sin línea: Punta triangular plena: indica el sentido de una asociación, es decir, el papel de una clase respecto a la otra.



UOC

TEMA – 3 EL MODELO DINÁMICO Y DE IMPLEMENTACIÓN ÍNDICE: 1) El diagrama de casos de uso 2) El diagrama de estados 3) Los de colaboración interacción: 3.1) diagramas Diagrama de 3.2) El diagrama de secuencias 4) El diagrama de actividades 5) Los diagramas de implementación: Diagrama de despliegue 1) EL DIAGRAMA DE CASOS DE USO Los diagramas de casos de uso sirven para mostrar las funciones de un sistema de software desde el punto de vista de sus interacciones con el exterior y sin entrar ni en la descripción detallada ni en la implementación de estas funciones. Un actor es un conjunto de papeles de una entidad exterior en relación con el sistema de software considerado. Los actores se representan mediante una figura humana esquemática:

Para ser actor, una entidad exterior tiene que cumplir estas dos condiciones: •

•

Ser autónoma con respeto al software, es decir, que la actividad en que utiliza la información suministrada por el software no esté subordinada a la de éste. Mantener relación directa con el software o con entidades exteriores que desempeñan tareas subordinadas a la actividad del software.

Un caso de uso documenta una interacción entre el software y un actor o más. Dicha interacción tiene que ser, en principio, una función autónoma dentro del software. Los casos de usos se representan mediante elipses de trazo continuo. A veces se agrupan todas las elipses dentro de un rectángulo que representa todo el software:

Relaciones entre casos de uso: Entre los casos de uso se pueden establecer tres tipos de relación:

a) Relaciones de extensión (extend): se dice que el caso de uso A extiende el B si dentro de B se ejecuta A cuando se cumple una condición determinada, es decir, es



UOC

opcional ejecutar el proceso (una segunda pantalla). A tiene que ser un caso de uso que también se pueda ejecutar de forma separada de B, y debe de tener el mismo actor primario que éste. Notación: La flecha discontinua, punta abierta, con estereotipo <>, va de la clase A a la B (es decir al revés). Ejemplo: El caso de uso “Ver detalle llamada” extiende a “Consultar listado” porque opcionalmente se puede seleccionar una llamada para ver información detallada sobre la misma:

b) Relaciones de inclusión (include): un caso de uso A está incluido dentro de los casos de uso B, C, etc., si es una parte de proceso común a todos éstos, es decir, implica ejecutar el proceso. A no es un caso de uso autónomo, en el sentido de que no tendrá actor primario, sino que siempre será puesto en funcionamiento por uno u otro de los casos de uso que lo incluyen. No obstante, su implementación no puede depender de éstos. Por tanto, la inclusión de casos de uso es esencialmente una forma de reutilización. Además cuando solo se incluye dentro de un solo caso de uso es opcional ponerlo (lo normal es que esté incluido dentro de VARIOS casos de uso). Notación: La flecha discontinua, punta abierta, con estereotipo <>, va de la clase B y C a la A. Ejemplo: Para llamar o enviar un SMS (casos de uso “Llamar” y “Enviar SMS”, es necesario marcar un número de teléfono (caso de uso “Marcar número”:

c) Relaciones de generalización/explotación: un caso de uso A es una especialización de otro caso de uso B si A realiza todo el proceso de B, más algún proceso específico. También afecta a los actores. Notación: Flecha como la de herencia de los diagramas de clase (modelo estático). Ejemplo 1: Un operario (actor “Operario”), puede hacer lo mismo que un usuario normal (actor “Usuario”), más otras opciones (casos de usos):



UOC

Ejemplo 2: Existe un listado solo de llamadas (caso de uso “Consultar llamadas”), y otro más completo que incluye las llamadas, los SMS y e-mails (caso de uso “Consultar listado”):

Ejemplo PEC2: Realizar un diagrama de casos de uso para una cabina telefónica que funciona de la manera siguiente: Cualquier usuario puede utilizar la cabina para hacer llamadas, para lo cual habrá de marcar primero el número de teléfono. La cabina también permite enviar mensajes SMS y, lógicamente, también es necesario marcar el número de destino. Otra funcionalidad que tienen los usuarios es enviar mensajes de correo electrónico y, en este caso, en lugar de un número de teléfono se introduce la dirección electrónica. Además de poder hacer lo mismo que cualquier usuario, los operarios pueden consultar el listado de usos que se han hecho desde la cabina. En concreto, el listado indica, por cada uso que se ha hecho de la cabina, desde la última visita del operario, de qué tipo de uso se trata (llamada, SMS o e-mail), la fecha y la hora. Opcionalmente, el operario puede seleccionar una llamada para ver información detallada sobre esta (número de destino, duración e importe). Los operarios también pueden consultar un listado sólo de las llamadas realizadas desde la cabina. En este caso, por cada llamada se muestra también la fecha y la hora y, opcionalmente, también se pueden ver más detalles de la llamada, como en el caso anterior.



UOC

2) EL DIAGRAMA DE ESTADOS Y TRANSICIONES A veces hay objetos cuyo comportamiento puede variar a lo largo del tiempo; cuando esto sucede, se dice que el objeto tiene estados. Existen algunos tipos de aplicaciones, como las de tiempo real, para las cuales el modelado de estados es especialmente importante. En el diagrama de estados o diagrama dinámico tenemos que distingir los siguientes elementos:

a)

Los Estados: son las diferentes situaciones en que se puede encontrar un objeto. Un estado lleva acabo alguna acción o espera que se produzca un acontecimiento. Un estado no corresponde a un instante en el tiempo, sino que el objeto o interacción permanece en éste un tiempo finito. Notación: La representación más sencilla de un estado es un retángulo con los vértices redondeados, tal y como podemos observar en la siguiente figura:

También tenemos el estado inicial y el estado final respectivamente:

Estado Inicial: Estado final:



UOC

b) Las Transiciones: Qué cambios de estado son posibles. Una transición simple consiste en que el objeto o interacción pasa de un estado (estado de srcen) a otro (estado de destino), que podría volver a ser el mismo:

En el caso más general, pasosecomienza cuando se produce un acontecimiento determinado y al mismoeste tiempo cumple una condición especificada (condición de guarda); entonces se pueden ejecutar unas acciones y se pueden enviar mensajes a objetos individuales o a conjuntos de objetos. Un estado puede tener transiciones de llegada, una de las cuales será el estado de destino, y transiciones de salida, una de las cuales será el estado de srcen. Las transiciones se representan mediante flechas continuas de punta abierta que van delestado de salida al de llegada. Con la flecha se encuentra una expresión (denominada cadena de la transición y/o acontecimiento) que presenta la siguiente sintaxis formal: signatura ‘[’ guarda ‘]’ ‘/’ acción ‘^’ envío

Puede haber varias acciones o envíos o no haber ninguno, y pueden estar mezclados. El orden en que aparecen es en el que se deben ejecutar. A continuación veremos una explicación de cada uno de los elementos de la cadena de transición: Signatura: tiene un formato que depende del tipo de acontecimiento. En • el caso de un acontecimiento de llamada o de señal, se define así: nombre_acontecimiento ‘(’ nombre_parámetro ‘:’ expresión_tipo ‘,’ ..‘)’

Si el acontecimiento es de tiempo, la signatura adopta una de estas formas: ‘after(’ expresión_de_tiempo ‘)’

donde expresión_de_tiempo consiste en una duración a partir de un srcen, o: ‘when(’ hora o fecha ‘)’ Finalmente, si el acontecimiento es de cambio, tendremos lo siguiente: ‘when(’ expresión_booleana ‘)’

Ejemplo: Cuando el saldo de la llamada sea 0, colgamos y terminamos



UOC

Guarda: es una expresión que puede tomar el valor verdadero o falso, escrita en pseudocódigo o en el lenguaje de programación que se utiliza. Ejemplo: Cuando el saldo sea suficiente, a parte de otras condiciones, se establece la comunicación:

•

Acción/Envío: es la especificación de una acción, en pseudocódigo o en el lenguaje de programación que se usa. En el caso de un acontecimiento diferido, debe aparecer la palabra clave defer como primera acción. Ejemplo: Se emite tono hasta que tiene lugar el acontecimiento “descolgar”, entonces se produce la acción “establecer_llamada” y se cambia de estado:

c)

Los Aconticimientos: Cuál es el hecho que los produce. Los acontecimientos son hechos que,e cuando se producen, pueden provocar transiciones de un estado en objetos interacciones y/o la ejecución de determinadas acciones. Están a otro incluidas dentro de la signatura de la transacción. Ejemplo: Acontecimiento descolgar (que da lugar a la acción establecer_llamada):

Un estado compuesto, es aquel en el que hay varios subestados posibles, cada uno de los cuales puede ser un estado compuesto a su vez o no. Los estados no compuestos se denominan estados simples. A un estado compuesto le corresponde un diagrama de subestados. Ejemplo: En la PEC2, el diagrama de subestados “Comunicación establecida”



UOC

Las Transiciones complejas se producen cuando un objeto o interacción puede estar en más de un estado al mismo tiempo, y puede haber transiciones que salgan de más de uno o que vayan a parar a más de uno, o ambas cosas a la vez. Ejemplo: Cuando llega una factura de una compra de material, pasa a estar pendiente de la verificación mediante la comparación con el pedido (V1) y con lo que se ha recibido (V2), por medio de una transición compleja de bifurcación; si de cada verificación resulta una conformidad (acontecimientos OK1 y OK2), se pasa al estado Revisado1 y Revisado2, respectivamente. Cuando llega el día 30, se paga la factura sólo si estaba al mismo tiempo en estos dos estados, por medio de una transición compleja de sincronización.

Ejemplo PEC2: Representar mediante un diagrama de estados los posibles estados de una llamada telefónica en una cabina: Inicialmente, cuando el usuario descuelga, la cabina está en estado de espera de dinero, donde permanecerá mientras el usuario no haya introducido monedas. Una vez el usuario empieza a pulsar las teclas numéricas, la cabina pasa a estar marcando el número mientras no se hayan introducido todos los dígitos. Cuando el número está completo, si hay suficiente dinero, la comunicación estará establecida. En caso de que no haya basta dinero en este punto, el usuario habrá de introducir más monedas. Cuando se establece la comunicación, lo primero que sucede es que se escucha el tono de llamada. Si el destinatario de la llamada descuelga, pasamos a estar hablando. En este momento la cabina graba que se ha establecido la llamada para



UOC

disminuir el saldo, cada 30 segundos mientras se esté hablando. Cuando el saldo llega a cero, finaliza la comunicación. Una vez establecida la comunicación, en cualquier momento (ya sea mientras se escucha el tono de llamada o bien mientras se está hablando) el usuario puede colgar y la cabina devolverá el saldo restante, pasando a estar libre para la próxima llamada.

3) DIAGRAMAS DE INTERACCIÓN: DIAGRAMA DE SECUENCIA El diagrama de secuencias está estructurado según dos dimensiones. El tiempo se representa verticalmente y corre hacia abajo, y no está representado a escala necesariamente. En dirección horizontal, hay franjas verticales sucesivas que corresponden a los diferentes papeles de clasificadores que participan en la interacción; cada papel de clasificador está representado por el símbolo habitual, que encabeza su línea de vida. La línea de vida simboliza la existencia del papel en un cierto periodo de tiempo. Se representa mediante una línea discontinua vertical que va desde la creación del objeto hasta su destrucción. Una activación (rectángulo alargado verticalemente, dentro de la línea de la vida) es una parte de la línea de vida durante la cual dicho papel ejecuta una acción, u otros papeles ejecutan otras acciones, como consecuencia de una acción ejecutada por el papel. Ejemplo de línea de vida y activación del objeto “Satélite”:



UOC

Los mensajes, se indican con flechas continuas terminadas en punta cerrada, que comienzan en una activación (al principio de ésta o por el medio) y acaban en otra. Ejemplo mensaje “comunicarDestino(d)”:

Las repuestas, o mensajes de retorno (suelen devolver un valor) al final de una activación, (sino es un mensaje normal que va hacia atrás) se representan en forma de flechas de línea discontinua y punta abierta. Ejemplo respuesta/mensaje de retorno del valor i (indicación):

Etiquetas condicionales en los diagramas de secuencia: •

Etiqueta “opt”: equivalente al “if”, viene a dar solo una alternativa. Ejemplo: Si existe desviación entre la posición “p2” y la indicación:

•

Etiqueta “alt”: equivalente al “if” con “else if”, es decir da varias alternativas (se pueden anidar y usa el [else]).



UOC

Ejemplo: Si el usuario es propietario, entonces mostrar la imagen, sino, si el usuario está autorizado, entonces mostrar la imagen:

Etiquetas de repetición (bucle) en los diagramas de secuencia: •

Etiqueta “loop”: equivalente al while, es decir repite mientras se cumpla una condición: Ejemplo: Se repite mientras p2 (posición) sea distinto de d (destino):

Ejemplo PEC2: Realizar un diagrama de secuencia que represente el funcionamiento de un GPS. El usuario del GPS siempre se comunica con su interfaz, el cual pasará los datos introducidos al controlador, que es el que se comunicará con el satélite. El usuario introduce la dirección de destino. Una vez recibida por el controlador, este pedirá la posición actual al satélite. Un vez obtenida esta posición, el controlador calculará la ruta desde la posición actual hasta la destino, y acto seguido dará las primeras indicaciones a la interfaz para que las muestre al usuario. Acto seguido, el controlador volverá a pedir la posición al satélite para verificar que el usuario sigue la ruta indicada. Mientras no se llegue al destino, el controlador irá dando las indicaciones correspondientes según la posición actual (la cual deberá consultar al satélite después de cada indicación) y, si detecta que el usuario se ha desviado de la ruta indicada, recalculará la ruta desde la nueva posición.



UOC

4) DIAGRAMAS DE INTERACCIÓN: DIAGRAMA DE COLABORACIÓN El diagrama de colaboración es la representación de una interacción mediante un diagrama estático de la colaboración correspondiente sobre la cual se representan los mensajes de la interacción. Para cada

mensaje hay una especificación con la siguiente sintaxis:

número_secuencia: [guarda] valores_de_retorno signatura

A continuación, daremos una explicación de cada elemento del mensaje: •

Número de secuencia (predecesores): es la lista de los mensajes predecesores de dicho mensaje que tiene esta forma: 1, 1.1, 1.1.1, etc. El número de secuencia del mensaje que pone en funcionamiento toda la interacción es 1, y los de los mensajes que envía en diferentes momentos



UOC

el proceso que ha puesto en marcha directamente son 1.1, 1.2, etc., mientras que si el mensaje 1.2 activa un proceso que envía a la vez dos mensajes (y se crean, entonces, dos hilos de ejecución) tendrán los números que se distinguirán por un nombre, como 1.2a y 1.2b. Los mensajes con nombres como 1, 1.3, 1.3.1, 1.3.1.2, etc., se dice que forman una secuencia. Ejemplo:

•

Guarda: es la condición que se tiene que cumplir para que se envíe dicho mensaje (además del hecho de que se hayan recibido los mensajes predecesores). Ejemplo: [p2 <> d]

•

Valores de retorno: especifica una lista de nombres de valores retornados –si los hay– como resultado del proceso puesto en marcha por el mensaje. Ejemplo: devuelve el valor i:

•

Signatura: está compuesta por el nombre del estímulo y por una lista de argumentos entre paréntesis. Ejemplo: calcularRuta entre posición “ p” y distancia “d”:

Notas: Normalmente el primer mensaje es asíncrono (se manda y el usuario sigue haciendo sus cosas):

y los demás (objetos) son síncronos (siguen en espera de las respuestas):



UOC

Además un mensaje de cálculo es sobre si mismo y redondo y devuelve una signatura, en bucle es cuadrado y lleva una Guarda para salir (ver ejemplo anterior).

Ejemplo PEC2: Realizar un diagrama de colaboración, basándose en el diagrama de secuencia que representaba el funcionamiento de un GPS.

5) DIAGRAMAS DE ACTIVIDAD: El diagrama de actividades se puede considerar una variante ta nto del diagrama de estados como de los diagramas de interacción, ya que sirve para describir los estados de una actividad, que es un conjunto de acciones en secuencia y/o concurrentes (workflow) en el que intervienen clasificadores. Este tipo de diagrama demuestra la serie de actividades que deben ser realizadas en un uso-caso, así como las distintas rutas que pueden irse desencadenando en el uso-caso. Un diagrama de actividad es utilizado en conjunción de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solución. Elementos que lo forman: •

Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido (igual que en el diagrama de estados).

•

Actividad: Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo.



UOC

Ejemplo: Actividad Buscar un libro

•

Clase/Entidad: Representa, no una actividad, sino una entidad, es decir, un objeto: Ejemplo: Clase Pedido

•

Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una linea con una flecha en su terminación para indicar dirección, (igual que en un diagrama de estados). La transición también puede apuntar a una clase/objeto cuando el paso a otra actividad depende de dicho objeto: Ejemplo: Una vez se hace el Pedido (clase “:Pedido”), se prepara (actividad “Preparar”) el paquete (clase “:Paquete”):

•

Ramificación Una ramificación cuando existe la posiblidad ocurra más de (Branch): una transición (o una u otra)ocurre al terminar determinada actividad.que Este elemento es representado a través de un rombo. Ejemplo: Se busca un libro, y se está disponible se hace el pedido, y sino se hace la reserva (reservar):



UOC

Unión (Merge): Una unión ocurre al fusionar dos o más transiciones en una sola transición o actividad.Este elemento también es representado a través de un rombo. Ejemplo: Tanto el pedido como la reserva desembocan en el envío del libro (ver ejemplo PEC2):

•

Expresiones Resguardadas (Guard) : Una expresió resguardada es utilizada para indicar una descripción explicita acerca de una transición. Este tipo de expresión es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transición (la misma que en diagrama de estados, y de interacción). Ver ejemplo de ramificación donde aparecen dos Guard.

•

Fork : Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional). Un fork es representado por una linea negra solida, perpendicualar a las lineas de transición.



UOC

•

Join : Una join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una linea negra solida, perpendicualar a las lineas de transición .

•

Fin : El fin de un diagrama de actividad es representado por un círculo, con otro circulo concentrico de color negro sólido (igual que el de diagrama de estados).

•

Canales (Swimlanes) : En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando acabo la actividad. Ejemplo: En un servicio de prestamo de lbros on-line de una biblioteca universitaria, tenemos la entidades usuario (el que hace el pedido), la recepción de la biblioteca (la que lo gestiona), y los envíos (el envío final del paquete):

•

Actividad en espera: En determinadas ocasiones una actividad está en espera o se encuentra en canales diferentes, en ese caso se muestra en punta de flecha (empieza) o con encaje de flecha (donde se acaba):

Ejemplo PEC2: Representar mediante un diagrama de actividades un servicio de préstamo de libros on-line ofrecido por una biblioteca universitaria. Los usuarios buscan en la página Web los libros en los que están interesados. Si están disponibles, hacen la petición correspondiente. Cuando esta llega a la recepción de la biblioteca, se prepara el paquete correspondiente al pedido y se pasa al departamento de envíos a domicilio. Una vez aquí, se programa el envío y, cuando corresponde, se hace la entrega a la vez que se avisa al usuario que próximamente lo recibirá. Cuando los libros pedidos no están disponibles, el usuario debe hacer una reserva,



UOC

que se transmite también a la recepción de la biblioteca. Esta permanecerá en espera hasta que el usuario que tiene el libro lo devuelva y, cuando esto sucede, inicia el proceso de preparación del pedido. Cuando el usuario recibe el aviso que se ha iniciado la entrega de su petición, espera la recepción y finaliza el proceso.

6) DIAGRAMA DE IMPLEMENTACIÓN: EL DIAGRAMA DE DESPLIEGUE El diagrama de despliegue permite mostrar la arquitectura en tiempo de ejecución del sistema respecto a hardware y software. Representa la estructura del sistema sólo en tiempo de ejecución, pero resulta más amplio en el sentido de que puede contener más clases de elementos. Los nodos representan objetos físicos existentes en tiempo de ejecución, sirven para modelar recursos que tienen memoria y capacidad de proceso, y pueden ser tanto ordenadores como dispositivos o personas (roles). Los componentes participan mediante éstos en los procesos. Los nodos se representan mediante paralelípedos rectangulares.



UOC

Relaciones dentro del diagrama de despliegue: Entre los nodos se establecen relaciones que significan que existe comunicación entre éstos. Se representan mediante líneas continuas, puede ser que con un estereotipo que indica el tipo de comunicación. Un componente o un objeto se puede ejecutar si se utilizan los recursos de un nodo o puede estar contenido en éste. En el primer caso, se da una dependencia con el estereotipo supports; en el segundo, se establece una relación de agregación o composición, que se puede representar de las maneras habituales. Se puede representar que un objeto o componente emigra de un nodo a otro o se transforma en otro. El primer caso se representa el objeto o componente en los dos nodos, y en los dos casos, la relación entre sí es una dependencia con el estereotipo becomes. Podemos tener asociada una propiedad que indique el tiempo en el que se producirá la migración. Además, entre componentes se pueden establecer las mismas relaciones mediante interfaces que en el diagrama de componentes, limitadas, pero en tiempo de ejecución.

Ejemplo PEC2: Representar el siguiente sistema mediante un diagrama de despliegue. El cliente GPS contiene un controlador que calcula el recurrido a realizar, así como un repositorio de mapas, que son mostrados por la interfaz gráfica. También existe la posibilidad de que la interfaz muestre las estaciones de servicio mediante un componente específico que las obtiene de un repositorio del servidor. El servidor también se encarga de calcular la posición actual del cliente, que es utilizada por el controlador del cliente a la hora de calcular el recorrido.



UOC

TEORIA DE EXAMEN Semestre 08 - 08 (examen 3) ¿Qué es un prototipo? ¿Para qué sirve? Solución: Módulo 1, apartado 2.2.2.

Un prototipo es un software provisional, construido con herramientas y técnicas que dan prioridad a la rapidez y a la facilidad de modificación antes que a la eficiencia del funcionamiento, que solo tiene que servir para que los usuarios puedan ver como sería el contenido o la apariencia de los resultados de algunas de las funciones del futuro software.

- A parte de ayudar a concretar los requisitos, el prototipo sirve para que los usuarios puedan confirmar que lo se muestra, efectivamente es lo que necesitan o bien lo que puedan pedir por comparación, y entonces se prepara una nueva versión del prototipo teniendo en cuenta las indicaciones de los usuarios y se les enseña nuevamente.

- Una vez que el prototipo, ha permitido concretar y confirmar los requisitos, se puede comenzar un desarrollo según el ciclo de vida en cascada, en este caso, no obstante, partiendo de una base más sólida.

- El ciclo de vida con prototipos no se puede considerar plenamente un ciclo de vida iterativo e incremental, ya que se elabora de forma iterativa y no necesariamente incremental.

Semestre 08 - 08 (examen 2) ¿Qué son las herramientas CASE? Solución: Módulo 1, apartado 4.


RESUMEN INGENIERÍA DEL SOFTWARE 1er SEMESTRE 2008-09 Las

UOC

herramientas CASE son software de apoyo al desarrollo, mantenimiento y

documentación informatizados de software.

- De esta definición se excluyen las herramientas que tienen una de las funciones siguientes: a) O bien no tienen solo esta finalidad (herramientas de texto, hojas de cálculo, de dibujo en general, planificación de proyectos de cualquier ingeniería) ya que pertenecen a otros ámbitos.

b) O bien se utilizan para codificar software (compiladores, entornos de cuarta generación, editores ordinarios de programas, etc.…)

- Quedan pues, principalmente las herramientas que ayudan a aplicar técnicas concretas de desarrollo y mantenimiento de software, gestionando la información sobre los elementos y conceptos que se utilizan en los métodos de desarrollo, como los siguientes:

a) Herramientas diagramáticas (clases, relaciones, etc.…)

b) Herramientas de gestión de la prueba y de gestión de la calidad en general

c) Herramientas de gestión de cambios

- Es importante que las herramientas estén integradas, ya que los posibles cambios que se realicen lleguen a todos los elementos de diferentes técnicas.

- La programación orientada a objetos, ha facilitado la estandarización de las técnicas y notaciones en el modelo conocido como UML, que ha generado un gran numero de herramientas CASE, basada en el.

Semestre 08 - 08 (examen 1) Explicar los inconvenientes del Ciclo de Vida en Cascada Autor: Fistandantilus con la c olaboración indirecta de Ice y zumix Página 35 de 48


UOC

Solución Módulo 1, apartado 2.2.1

El inconveniente del modelo del ciclo de vida en cascada es que no es realista.

- Las sucesivas etapas del desarrollo se hacen de forma lineal, de manera que una fase no comienza hasta que no se haya acabado la anterior y no se vuelve nunca a otra etapa anterior.

- El problema más grave que se presenta, en el análisis de requisitos, es que estos requisitos son casi siempre incompletos al principio o cambian antes de que se haya acabado de construir el software.

- Las razones por las cuales es prácticamente imposible elaborar unos requisitos completos y estables en el primer intento son:

a) Los futuros usuarios, es difícil que conozcan suficientemente el entorno en el que se tiene que utilizar el software.

b) El trabajo de consolidación de las peticiones de estos usuarios será casi siempre imperfecta.

¿Cómo se resuelven?: Se resuelve mediante el ciclo iterativo e incremental basado en el ciclo de vida en cascada, aplicando en cada etapa del análisis de requisitos y no a todo el conjunto del software.

Semestre 07 - 08 (examen 3) Qué grandes fases se identifican en el modelo RUP (Rational Unified Process)? Descríbalas brevemente. Solución: Autor: Fistandantilus con la c olaboración indirecta de Ice y zumix Página 36 de 48


UOC

Módulo 1, pág. 16

El modelo RUP (Rational Unified Process) es un ciclo de vida iterativo e incremental. Las cuatro fases son:

1)

Inicio: es la que establece la justificación económica del software y se

delimita el alcance del proyecto. 2)

Elaboración: se estudia el dominio del problema (actividad de la empresa

en el cual se utiliza el software), teniéndose en cuenta las necesidades de información y requisitos no funcionales y restricciones,

se establece la

arquitectura general del software y se realiza la planificación del proyecto.

3)

Construcción: se desarrolla todo el producto de forma iterativa e

incremental, con las necesidades de información y desarrollo de la arquitectura obtenida en la fase anterior.

4)

Transición: se hace entrega del producto al cliente y el comienzo de su

utilización, aunque se pueden hacer modificaciones y / o añadir nuevas funciones, porque se detectan errores o requisitos que no se han tenido en cuenta anteriormente. En cada una de las fases se llevan a término (en diferentes proporciones) los siguientes procesos:

-

Recogida de requisitos

-

Análisis de diseño.

-

Implementación (realización)

-

Prueba (test)

Semestre 07 - 08 (examen 2) Parecidos y diferencias entre el Ciclo de Vida con Prototipos y el Ciclo de vida de la Programación Exploratoria. Autor: Fistandantilus con la c olaboración indirecta de Ice y zumix Página 37 de 48


UOC

Solución: Módulo 1, Pág. 15-16

Ciclo de vida con prototipos: es un software provisional, construido con herramientas y técnicas que dan prioridad a la rapidez y a la facilidad de modificación antes que a la eficiencia del funcionamiento, que solo tiene que servir para que los usuarios puedan ver como sería el contenido o la apariencia de los resultados de algunas de las funciones del futuro software.

Ciclo de vida de la programación exploratoria: consiste en elaborar una primera versión del software, o parte de esta, se le enseña a los usuarios para que la critiquen y a continuación, se hacen los cambios que estos sugieren, esto se hace cuantas veces sean necesario.

Semejanzas: - Son un ciclo de vida iterativo pero no incremental (el prototipo no necesariamente incremental)

- Los dos ciclos sirven para que los usuarios vean como es el software o se hagan una idea de cómo es desde el principio.

Diferencias: - La principal diferencia es que la programación exploratoria es un software real desde el principio.

- La calidad del software desarrollado y su documentación en programación exploratoria tiende a ser más deficiente que los prototipos.

Semestre 07 - 08 (examen 1) Defina qué es la ingeniería del software y porque la calidad es uno de los principales problemas a los cuales se enfrenta. Idem Semestre 06 - 07 (examen 2)



UOC

Semestre 07 - 07 (examen 3) Explique en qué consiste el ciclo de vida Clásico. Enumere de manera ordenada qué etapas lo forman y comente muy brevemente cual es el objetivo de cada una de ellas. Solución Módulo 1, apartado 2.1

- Ciclo de vida del software: está constituido por el conjunto de todas las etapas (que la forman, que se enumeran más adelante). Los métodos y técnicas de la ingeniería del software se inscriben dentro del marco delimitado por el ciclo de vida, más concretamente, por las diferentes etapas que lo forman.

El ciclo de vida clásico, también se denomina ciclo de vida en cascada, lo cual quiere decir que en cada etapa se obtiene una documentación (“derivable”) que son las bases de partida de la etapa siguiente, por lo cual no se puede comenzar una etapa si no se ha terminado la anterior y además no se regresa nunca a las etapas pasadas.

Las etapas son las siguientes:

1 Etapa de análisis previo: en esta etapa se definen los grandes rasgos del sistema de software que tendrá que dar soporte informático a unas actividades determinadas de ciertos usuarios en un marco general de una organización o empresa

2 Etapa de análisis de requisitos: tiene como objetivo definir con detalle las necesidades de información que tienen que resolver el software sin tener en cuenta por el momento los medios técnicos (lenguaje de programación, gestión de base de datos, componentes que se pueden reutilizar, etc.…) con los que se tendrá que llevar a cabo el desarrollo del software.

3 Etapa de diseño: el diseño especifica una solución al problema “que tiene que hacer el software” o como “el software tiene que hacer su función”



UOC

4 Etapa de programación o codificación: consiste en traducir el diseño a código procesable por el ordenador.

5 Etapa de prueba: consiste en probar el software desde distintos puntos de vista de una manera planificada, para localizar y corregir dentro del software y su documentación los errores que se detecten.

6 Etapa de mantenimiento o explotación: siempre que se utilice el software habrá que mantenerlo, hacer cambios (pequeños o grandes), para corregir errores, mejorar las funciones o la eficiencia o adaptarlo a un nuevo hardware u otros cambios en las necesidades de información.

Semestre 07 - 07 (examen 2) Comente cuál es el objetivo de la etapa de Diseño dentro del Ciclo de Vida Clásico. Diga también entre qué dos etapas se encuentra y explíquelas muy brevemente. Solución Módulo 1, Sección 2.1.1

Análisis de requisitos: tiene como objetivo definir con detalle las necesidades de información que tienen que resolver el software sin tener en cuenta por el momento los medios técnicos (lenguaje de programación, gestión de base de datos, componentes que se pueden reutilizar, etc.…) con los que se tendrá que llevar a cabo el desarrollo del software.

- Se debe obtener información de los usuarios y de otras fuentes (como el software que se debe sustituir, un software que desempeña funciones parecidas, etc.…), esto permitirá hacerse una idea precias de las funciones y requisitos en el futuro software.

- Con esta información se redacta un documento que denominamos “especificación de requisitos” por los motivos siguientes:



UOC

a) Especificar que tiene que hacer el software con la suficiente precisión para poder desarrollarlo.

b) Servir de base para un contrato, explicito o no, entre el equipo de desarrollo y el cliente.

Se encuentra entre la etapa análisis previo (etapa de análisis de sistemas o ingeniería de sistemas) y la etapa de diseño.

Etapa análisis previo: En esta etapa se definen los grandes rasgos del sistema de software que tendrá que dar soporte informático a unas actividades determinadas de ciertos usuarios en un marco general de una organización o empresa

Etapa de diseño: El diseño especifica una solución al problema “que tiene que hacer el software” o como “el software tiene que hacer su función”

Semestre 07 - 07 (examen 1) Explique en qué consiste el análisis de requisitos del Ciclo de Vida Clásico. Comente qué se obtiene como resultado de esta etapa y qué funciones tiene este resultado.

Solución: Módulo 1, Sección 2.1.1

Análisis de requisitos: tiene como objetivo definir con detalle las necesidades de información que tienen que resolver el software sin tener en cuenta por el momento los medios técnicos (lenguaje de programación, gestión de base de datos, componentes que se pueden reutilizar, etc.…) con los que se tendrá que llevar a cabo el desarrollo del software.

- En esta etapa se detalla los requisitos de la etapa de análisis previo (que se definen los grandes rasgos del sistema de software que tendrá que dar soporte informático a unas



UOC

actividades determinadas de ciertos usuarios en un marco general de una organización o empresa)

- Se debe obtener información de los usuarios y de otras fuentes (como el software que se debe sustituir, un software que desempeña funciones parecidas, etc.…), esto permitirá hacerse una idea precias de las funciones y requisitos en el futuro software.

- Con esta información se redacta un documento que denominamos “especificación de requisitos” por los motivos siguientes:

a) Especificar que tiene que hacer el software con la suficiente precisión para poder desarrollarlo.

b) Servir de base para un contrato, explicito o no, entre el equipo de desarrollo y el cliente.

Semestre 06 - 07 (examen 2) Los grandes problemas de la ingeniería del software: la calidad y la productividad Solución: Módulo 1, página 8

- La calidad del software como la productividad de su elaboración no han alcanzado niveles comparables con otras tecnologías más antiguas.

-Referente a la calidad, la causa principal de las dificultades es la gran complejidad del software comparado con otro tipo de productos, como por ejemplo no se puede probar el funcionamiento de un software en todas las combinaciones de condiciones que se puedan dar.

- Los mercados cada vez están más saturados y son más exigentes, es lo que hace considerar como un factor de competitividad, ya que se le da cada vez más importancia a la calidad en todos los ámbitos y cada vez adquiere más importancia en el tema de la



UOC

calidad (garantía de calidad y certificaciones oficiales de calidad)

-

Referente a la productividad, una fabricación en serie tiene una productividad más

elevada que una fabricación singular, pero además, en el desarrollo del software si lo comparamos con otras producciones singulares la productividad es inferior. Una de las diferencias comparadas con otras tecnologías en un proyecto software es que empieza prácticamente de cero, aunque actualmente se utilizan fragmentos de software (prefabricados) mientras en la ingeniería mecánica o de obra civil, por ejemplo utilizan muchísimos elementos estándares como prefabricados (tornillos, baterías, motores, ventanas, vigas, grifos, etc.) por lo cual uno de los grandes retos de la ingeniería del software conseguir desarrollar fragmentos de software (componentes) que sean reutilizables, como ya están hechos y seguramente probados, aumentara la productividad y calidad del software, una de las vías con las cuales se quiere conseguir una cierta reutilización en el desarrollo orientado a objetos es mediante componentes otras vías son los patrones de diseño y marcas o frameworks.

Semestre 06 - 07 (examen 1) Para que se usa el modelo estático y el modelo dinámico en UML. Enumere los diagramas que se usan en cada uno de estos modelos. Solución: Módulo 2, pág. 7, Módulo 3, pág. 5

Modelo estático, de UML es aquel que se describen las clases y objetos, se denomina estático porque muestra todas las relaciones posibles a lo largo del tiempo, pero no las relaciones que son validas en un momento determinado.

-El modelo estático se utiliza en todas las etapas del ciclo de vida, en las diferentes etapas

se documentan diferentes tipo de objetos, en el análisis se

consideran objetos del mundo del usuario, por ejemplo facturas, usuarios, etc.) y en el diseño, se consideran los objetos de la tecnología informática por ejemplo, pantalla, gestores de discos, etc.



UOC

- Diagramas estáticos: El diagrama de clases El diagrama de objetos

Modelo dinámico, de UML se utiliza para modelar los aspectos dinámicos o de comportamiento de un sistema que se quiere desarrollar de manera orientada a objetos.

- Diagramas Dinámico: El diagrama de casos de usos. El diagrama de estados y transiciones. El diagrama de actividad El diagrama de interacción: diagrama de secuencias y diagrama de colaboración.

Semestre 06 - 06 (examen 2) Explique en qué consisten los ciclos de vida iterativos e incrementales y cuales son los motivos que los srcinan. Solución: Módulo 1, apartado 2.2.1

Los ciclos de vida iterativos e incremental consiste en elegir pequeñas partes de los requisitos que tengan una cierta autonomía, se diseña, se programa y se prueba, si el cliente lo da por bueno, se pasa a hacer lo mismo con otra parte del proyecto, de esta forma partimos de un software construido en parte, y podemos saber de los requisitos restantes de una forma más precisa y hacer una estimación más segura sobre el coste y duración del proyecto.

- Los motivos que srcinan “el ciclo de vida iterativo e incremental son los siguiente:



UOC

a) Los costes y la duración del proyecto se calculan sobre una base poca sólida y tiene un gran margen de error.

b) El análisis de requisitos son casi siempre incompletos al principio o cambian antes de que se haya finalizado de construir el proyecto, que da lugar a que en las etapas de diseño y programación suelen haber problemas por este motivo. - Hay dos razones por el cual es prácticamente imposible elaborar unos requisitos completos y estables en el primer intento:

a) Es difícil que los futuros usuarios conozcan suficientemente el entorno en el que se tiene que utilizar el software, que hayan reflexionado suficientemente sobre lo que se quiere conseguir y además que se pongan de acuerdo.

b) El trabajo de consolidación de las peticiones de los usuarios no será perfecto.

Semestre 06 - 06 (examen 1) Explique las principales diferencias entre los métodos estructurados y los métodos orientados a objetos, y diga cuales son las principales ventajas de estos últimos. Solución: Módulo 1, apartados 3.1 y 3.2

Los métodos estructurados provienen de la programación estructurada y se utilizan técnicas no muy integradas entre si, mientras que los métodos orientados a objetos tiene sus raíces en la programación orientada a objetos, que gira en torno al concepto de clase.

Las técnicas en los métodos estructurados son los diagramas entidad – relación (datos) y flujo de datos (procesos),

en cambio en los métodos



UOC

orientados a objetos son los diagramas de clases y objetos, y en las clases tenemos atributos (datos) y operaciones (procesos)

Las técnicas en los métodos estructurados se basan en top-down y bottom-up,

en los métodos orientados a objetos se basan en grupos de clases interrelacionadas.

Ventajas de los métodos orientados a obj etos: - Una de las ventajas es la reutilización del software en un grado significativo (las clases), solucionan en mayor o menor medida los problemas de productividad y calidad.

-Su relativa simplicidad facilita el desarrollo de herramientas informáticas de ayuda al desarrollo (notación UML)

Semestre 05 - 06 (examen 3) Exposa en unes 10 línies perquè el programari es pot considerar un producte industrial i quines característiques té comparat a d’altres productes industrials. Solució: Mòdul 1, ap. 1.2

El software como producto industrial: un software no es una obra de arte, sino un producto de consumo utilitario y masivo. Para una empresa o trabajador autónomo, el software es un medio auxiliar que interviene de manera más o menos directa en su gestión y cada vez más en su proceso productivo. También existe un consumo privado se software, por lo tanto se puede considerar plenamente como un producto industrial.

- Los bancos, industrias de fabricación en serie, empresas de comercio electrónico, etc.…, actualmente no podrían funcionar sin software.



UOC

- El software, es un producto industrial con algunas características especiales, es más un producto singular que un producto que se fabrique en serie, aunque existe software que tiene miles, millones de usuarios (por ejemplo, las copias de Sistemas Operativos) pero esto es una actividad poco importante dentro del conjunto productivo (la fabricación en serie)

- Una característica del software, es que no se estropea por el uso o paso del tiempo, si finalmente se sustituye el software es porque se ha quedado tecnológicamente anticuado o inadaptado a las nuevas necesidades o resulta demasiado caro mantenerlo.

- La producción del software se parece (desde un cierto punto de vista) a la construcción de viviendas o edificios industriales, el hecho de que cada producto es diferente y su elaboración se basa en un proyecto específico (en caso de producción en serie, se proyecta un prototipo del producto y no para cada unidad que se produce)

Semestre 05 - 06 (examen 2) Exposa en unes 15 línies com a màxim els problemes de qualitat i productivitat en l’enginyeria del programari. Idem Semestre 05 - 06 (examen 2)

Semestre 05 - 06 (examen 1) Enumera i descriu en unes 15 línies com a màxim les fases del cicle de vida clàssic. Idem Semestre 06 - 07 (examen 2)

Semestre 05 - 05 (examen 2) ¿Qué es un requisito? Explica los tipos de requisitos que existen y pon un ejemplo de cada uno. Solución: Mòdul 4, apartats 1 i 1.1



UOC

Los requisitos: son la especificación de lo que tiene que hacer el software, son descripciones del compartimiento, propiedades y restricciones del software que hay que desarrollar.

- Los requisitos deben indicar que debe realizar el software de la forma: a) No debe contener requisitos extremadamente abstractos, ya que los desarrolladores son técnicos y el cliente no tiene porque. b) Tienen unas referencias mínimas de la tecnología utilizada. c) El software tiene que ser compatible con el entorno técnico y organizativo.

- Los requisitos juegan un doble papel: a) servir de base para un acuerdo entre los usuarios y desarrolladores (empresa y cliente) desarrollando una documentación que ambas partes entiendan. b) Los requisitos son la información de partida para desarrollar el software de entrada para la etapa siguiente, el análisis.

Clases de requisitos: a) Requisitos funcionales: describe que se debe realizar el software para sus usuarios, como aceptar, verificar, registrar datos, transformarlos, presentarlos, etc.…(Quedan recogidos en los casos de uso)

b) Los requisitos no funcionales no van asociados a casos de uso concretos y consiste

en

restricciones

impuestas

por

el

entorno

y

la

tecnología,

especificaciones sobre el tiempo de respuesta o volumen de información, requisitos e interfaces, extensibilidad, facilidad de mantenimiento, etc.… (Casos de usos ficticios)

Semestre 05 - 05 (examen 1) Explica cuáles son los principales inconvenientes del ciclo de vida clásico y cómo se resuelven: Idem Semestre 08 - 08 (examen 1)


Ingeniero en Informática. Facultad de Informática. Arquitectura del Software. Prácticas. 2006/2007.

Seminario de Magic Draw Miguel Ángel Orenes Fernández Pedro Luis Mateo Navarro

______________________________________________________________________ M Gu daegíaicDraw

P

ágina 1

Índice Objetivos ...........................................................................................................................3 Consejos para el uso de esta guía......................................................................................4 Desarrollo..........................................................................................................................5 El proyecto de Magic Draw..........................................................................................5 Crear un proyecto nuevo...............................................................................................5 Diagramas UML................................................................................................................6 Diagrama de Casos de Uso...........................................................................................6 Elementos más importantes de este tipo de diagrama..............................................6 Pasos para llevar a cabo la realización del diagrama...............................................7 Diagrama de Clases....................................................................................................10 Elementos más importantes de este tipo de diagrama............................................10 Pasos para llevar a cabo la realización del diagrama.............................................11 Modelo conceptual......................................................................................................13 Elementos más importantes de este tipo de diagrama............................................13 Pasos para llevar a cabo la realización del diagrama.............................................14 Diagrama de Secuencia...............................................................................................17 Elementos más importantes de este tipo de diagrama............................................17 Pasos para llevar a cabo la realización del diagrama.............................................19 Diagrama de Colaboración.........................................................................................25 Elementos más importantes de este tipo de diagrama............................................25 Pasos para llevar a cabo la realización del diagrama.............................................26 Diagrama de Estados..................................................................................................29 Elementos más importantes de este tipo de diagrama............................................29 Pasos para llevar a cabo la realización del diagrama.............................................31 Diagrama de Actividades............................................................................................34 Elementos más importantes de este tipo de diagrama............................................34 Pasos para llevar a cabo la realización del diagrama.............................................35 Generar Código...............................................................................................................36 Generar Informes.............................................................................................................37 Referencias......................................................................................................................40


P

ágina 2

Objetivos –

Aprender a manejar los fundamentos de Magic Draw, la herramienta de soporte al modelado con UML que vamos a utilizar en prácticas.

–

Comprender la estructura de un modelo UML en Magic Draw

–

Crear los elementos de los modelos y diagramas de UML

–

Estructurar los elementos anteriores a través de paquetes

–

Generar código automáticamente a partir de los modelos


P

ágina 3

Consejos para el uso de esta guía En esta guía se explica el desarrollo de los diferentes diagramas UML utilizando la herramienta de modelado Magic Draw. Para cada uno de los diferentes tipos de diagramas, encontraremos la siguiente información: –

pasos iniciales para la creación del diagrama

–

elementos más importantes que aparecen en el diagrama (cabe señalar que en este apartado solamente hemos incluido los elementos más importantes, aunque la herramienta Magic Draw, en la mayoría de las ocasiones, proporciona un abanico más amplio para la realización de los mismos)

–

creación de un diagrama de ejemplo, en el que se explican los pasos más importantes

Al final de la guía, encontraremos dos apartados finales, correspondientes con la generación de informes y la generación de código.


P

ágina 4

Desarrollo El proyecto de Magic Draw Toda la información del proyecto se guarda en un único fichero. El nuevo proyecto creado estará formado por los siguientes paquetes: -

Paquete de datos inicialmente vacío, que guardará todos los elementos del modelo.

-

Paquete de visualizaci ón de las vistas (File View) que contendrá los elementos creados durante la implementación del código. Básicamente contendrá los ficheros fuente.

-

UML Standard Profile contiene los estereotipos que son necesario para

trabajar con MagicDraw, tipos de datos primitivos, y sus restricciones, que son del estándar de UML, y los elementos del meta modelo de UML 2.0. Para utilizar Magic Draw Y empezar a trabajar con la herramienta, es necesario crear un proyecto sobre el que iremos trabajando.

Crear un proyecto nuevo Para crearlo, seguiremos los siguientes pasos: 1. crearemos una carpeta con el nombre que queramos. Ésta será la carpeta contenedora de nuestro proyecto 2. con la herramienta ya abierta, haremos clic en la opción “File -> New Project”. La aplicación procederá a crear un nuevo proyecto 3. una vez termine de crear el proyecto, usaremos la opci ón “File -> Save Project As...” para guardarlo. Seleccionaremos la carpeta contenedora que hemos creado

en el paso 1, pondremos un nombre al proyecto y pulsaremos el botón de “Save”. Ya tendremos creado un proyecto vacío sobre el cual poder trabajar.


P

ágina 5

Diagramas UML Diagrama de Casos de Uso Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> Use Case Diagram ”.

Elementos más importantes de este tipo de diagrama

Actor Representa los roles que juegan los usuarios en el sistema

Caso de Uso Especifica un comportamiento en particular del sistema

Asociación

Participación de un actor en un caso de uso

Generalizaci ón


P

ágina 6

Pasos para llevar a cabo la realización del diagrama 1 Añadir elementos al diagrama

Para añadir un nuevo elemento al diagrama debemos hacer clic derecho sobre la carpeta Data del árbol de contenidos (Containment tree) y seleccionar "New Element --> X", donde X será el elemento que queramos crear (actor, caso de uso,...). Le asiganaremos un nombre único. De este modo se añadirá a la lista del árbol de contenidos el nuevo elemento creado.

El resto de los elementos que compondrán el diagrama los crearemos de la misma forma. Una vez creados todos los elementos que participarán en el diagrama, los añadiremos simplemente haciendo clic con el botón izquierdo sobre ellos y arrastrándolos hacia el “grid” del diagrama. Como ya habrás observado, en la parte inferior izquierda de la vista del diagrama de casos de uso aparecen los símbolos de los diferentes elementos que se pueden crear. Se recomienda que se creen de la manera vista anteriormente, ya que nos dará la seguridad de tener sólo los elementos necesarios para nuestro diagrama. A la hora de borrar un elemento del diagrama se debe ser cauto, ya que si lo eliminas de la vista grafica, no desaparece del modelo, es decir, lo quitamos del diagrama pero no de los elementos que forman el proyecto. Para eliminar cualquier elemento del proyecto habrá que hacer clic derecho sobre dicho


P

ágina 7

elemento en del árbol de contenidos (Containment tree) y selecionar la opción eliminar (delete). 2 Establecer relaciones entre los elementos del diagrama

Podemos observar como cuando seleccionamos un elemento ( en este caso un actor) aparecen a su derecha los símbolos de las posibles relaciones en las que puede participar, lo que nos dará la facilidad de no tener que ir a buscarlas a una paleta de herramientas, ya que con sólo hacer clic sobre la relación, podremos establecerla simplemente arrastrando el puntero del ratón hacia el elemento destino. Ejemplo de diagrama de Casos de Uso:


P

ágina 8

Para guardar el diagrama simplemente tendremos que hacer clic sobre el menú “File -> Save project”, y el nuevo diagrama que hemos creado quedará guardado en nuestro

proyecto.


P

ágina 9

Diagrama de Clases Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> Class Diagram”.


Clase

Enumeración

Interfaz

Paquete

Generalizaci ón

Asociación

Relación de implementación con interfaz

______________________________________________________________________ M Gu daeígaicDraw

P

ágina

10

Pasos para llevar a cabo la realización del diagrama 1 Añadir elementos al diagrama

Crearemos los elementos de la misma forma que se explicó en el apartado anterior. Para añadir un nuevo elemento al diagrama debemos hacer clic derecho sobre la carpeta Data del árbol de contenidos (Containment tree) y seleccionar "New Element --> X", donde X será el elemento que queramos crear (clase, interfaz,...). Le asiganaremos un nombre único. Una vez creados todos los elementos que participarán en el diagrama, los añadiremos haciendo clic con el botón izquierdo sobre ellos y arrastrándolos hacia el “grid” del diagrama. Ya tendremos el diagrama preparado para establecer todas las relaciones necesarias.

2 Establecer relaciones entre los elementos del diagrama

Una vez que tengamos todos los elementos colocados en el diagrama, empezaremos a establecer las relaciones entre ellos. Para ello, seguiremos el mismo método explicado antes: hacer clic con el botón izquierdo sobre el elemento, seleccionar la relación que queramos establecer y arrastrar el puntero del ratón hasta el elemento destino de la relación. 3 Insertar métodos y atributos a las clases

Para insertar nuevos métodos a una clase/interfaz, haremos clic con el botón derecho sobre el elemento objetivo y seleccionaremos en el menú contextual la opción “Insert New Operation”. Introduciremos el nombre correspondiente y aceptaremos pulsando la tecla intro. Ya tendremos añadido un nuevo método para esa clase o interfaz.

Para insertar nuevos atributos procederemos de la misma forma, aunque lo haremos seleccionando la opción “Insert New Atribute”


P

ágina

11

Ejemplo de diagrama de clases:


P

ágina

12

Modelo conceptual Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> Class Diagram” (notar que el modelado conceptual también consiste en un

diagrama de clases, pero un tanto especial).


Clase

Asociación

Notas


P

ágina

13

Pasos para llevar a cabo la realización del diagrama La forma de llevar a cabo la realización de esta diagrama es similar a la del diagrama de clases, pero cabe añadir la forma en que introduciremos las cardinalidades entre las clases que componen nuestro modelado conceptual. Una vez creadas todas las clases, comenzaremos a crear todas las relaciones. Para crear relaciones, a las que posteriormente añadiremos cardinalidades, usaremos el tipo de relación sin dirección . Para añadir cardinalidades a las asociaciones, haremos clic con el botón derecho del raton sobre la linea que representa la asociación, apareciéndonos el siguiente menú contextual:

Las dos opciones de abajo corresponden con las cardinalidades a ambos extremos de la relación, que en este ejemplo se tratan de las clases “Venta” y “Linea de Venta”. Si ahora situamos el puntero del ratón sobre alguna de las dos opciones, se nos aparecerá otro menú contextual en el que podremos elegir la cardinalidad que deseemos.


P

ágina

14

Como podemos observar, en el menú de la izquierda, en la parte de abajo, encontramos las cardinalidades disponibles. Para seleccionar una de ellas, simplemente haremos clic con el botón izquierdo sobre una de las opciones disponibles y automáticamente se añadirá al diagrama que estamos creando, como se muestra en la imagen a continuación:

El resto de las cardinalidades las introduciremos siguiendo los mismos pasos.


P

ágina

15

Por último, en estos tipos de diagramas es muy común añadir notas para aclarar los conceptos. Para ello, simplemente añadiremos una nueva nota al diagrama haciendo clic sobre el botón

y haciendo clic de nuevo en la zona del diagrama donde queramos

añadirla. Introduciremos el texto correspondiente por teclado y llevaremos a cabo la asociación de la nota con el elemento al que se refiere. Haremos clic sobre la nota que acabamos de crear, y se nos presentará la siguiente situación:

Haremos clic sobre el botón que nos aparece situado a la derecha de la nota y arrastraremos hasta el elemento con el cual queramos relacionarla. El resultado es el siguiente:


P

ágina

16

Diagrama de Secuencia Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> Sequence Diagram ”.

Una vez creado aparecerá como parte del caso de uso, y lo único que tenemos que hacer es cambiarle el nombre:


Linea de vida de un objeto

Mensaje

Automensaje

Mensaje Recursivo


P

ágina

17

Mensaje Diagonal


P

ágina

18

Pasos para llevar a cabo la realización del diagrama Una vez creado el diagrama de secuencia para el caso de uso Realizar Venta , debemos de crear la clase Sistema. Para ello hacemos clic derecho sobre la carpeta Data del Containment tree y seleccionamos New Element --> Class.

Una vez creada la clase, procedemos a introducir el actor Cajero y la clase Sistema en el diagrama de secuencia creado. Para ello los arrastraremos con el rat ón:

Como se puede observar en la parte izquierda de la vista del diagrama de secuencia, aparecen los elementos para este tipo de diagrama. Ahora proseguimos introduciendo los mensajes. Para ello seleccionamos el elemento Message :


P

ágina

19

Y hacemos clic sobre la línea de tiempo del Cajero y seguidamente sobre la clase sistema.

Podemos observar que hemos creado un nuevo mensaje entre los dos elementos que acabábamos de introducir. Una vez echo esto, haremos clic derecho sobre el nuevo mensaje creado y seleccionamos Specification:

Y nos aparecerá la siguiente ventana, donde aparecen todas las propiedades relacionadas con el mensaje que acabamos de crear:


P

ágina

20

Tendremos que realizar los siguiente pasos: -

El campo Message Type contendrá el tipo "Send Message".

-

En el campo Name, introduciremos el nombre del mensaje correspondiente, en nuestro caso introducirItem.

-

Pulsar Close para confirmar los cambios .

Como se puede observar, el mensaje aparecerá ahora con nombre:

En el caso de que al mensaje creado queramos añadirle parámetros, debemos hacer lo siguiente: 1- Volvemos a abrir la especificaci ón (clic derecho y seleccionamos Specification). 2- Seleccionamos la opción Arguments que aparece en la parte izquierda de la ventana. 3- Pulsar Create


P

ágina

21

4- En el men ú que se despliega, seleccionamos la opción que queramos., en nuestro caso elegiremos Element Value, ya que queremos pasarle dos enteros como parámetros. El tipo tendremos que buscarlo entre los predefinidos por UML.

5- Buscamos la clase int en la ventana que aparece y hacemos clic sobre OK:

Repetiremos el proceso para añadir otro parámetro entero.


P

ágina

22

La ventana de argumentos quedará de la siguiente manera:

Seleccionamos Close para confirmar los cambios y nos quedará el siguiente diagrama de secuencias:


P

ágina

23

Ahora solamente nos quedará crear otros dos mensajes (terminarVenta() y

realizarPago() ) de igual forma que acabamos de crear este mensaje, quedándonos el diagrama como se muestra en la siguiente imagen:


P

ágina

24

Diagrama de Colaboración Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> Communication Diagram”.


Objeto participante

Conector

Autoconector

Mensaje a la derecha

Mensaje a la izquierda

Mensaje de llamada a la derecha

Mensaje de llamada a la izquierda


P

ágina

25

Pasos para llevar a cabo la realización del diagrama Para ilustrar como se crean este tipo de diagramas, vamos realizar el diagrama de colaboración de la operación del sistema IntroducirItem . Seguiremos los siguientes pasos: –

Se añaden las clases necesarias (que fueron creadas ya con el diagrama de clases) y el actor (creado al hacer el diagrama de casos de uso) al diagrama arrastrándolos desde el Containment Tree. Si no están creadas creamos las clases TPV, Venta, LineaVenta, CatalogoProducto y producto; y el actor cajero.

–

Ahora pasamos a crear los mensajes. Para ello primero es necesario crear un

conector entre los dos elementos que se comunican, que lo haremos haciendo clic sobre el icono

que aparece en la ventana del diagrama de colaboración.

Haremos clic sobre el actor Cajero y arrastraremos hasta la clase TPV, por lo que ya quedarán conectados, como se muestra en la imagen:

–

Una vez conectados, añadiremos un nuevo mensaje haciendo clic sobre el icono y posteriormente haciendo clic sobre el conector que acabamos de crear, con el fin de asociar el mensaje que nos disponemos a crear con el conector que creamos anteriormente. El resultado es el siguiente:


P

ágina

26

Introducimos el nombre correspondiente al mensaje, y para añadirle argumentos lo haremos del mismo modo que lo hicimos para el diagrama de secuencias. Tras añadirle un nombre y los correspondientes argumentos al mensaje, su especificación quedaría de la siguiente manera:


P

ágina

27

Aceptaremos los cambios haciendo clic sobre el botón “Close”, siendo el resultado el siguiente:

Donde podemos apreciar dos elementos: –

el conector que asocia a Cajero y a TPV

–

el mensaje que representa la comunicación entre ellos

Ahora, continuaremos introduciendo el resto de conectores y mensajes del mismo modo que acabamos de explicar, siendo el resultado el siguiente:


P

ágina

28

Diagrama de Estados Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> State Diagram”.


Estado

Estado compuesto

Estado ortogonal

Estado Inicial

Estado final

Punto de entrada

Punto de salida

Transición de estado


P

ágina

29

Autotransición

Unión/división de transiciones


P

ágina

30

Pasos para llevar a cabo la realización del diagrama Comenzaremos introduciendo los estados inicial y final, que siempre deben de estar presentes en un diagrama de estado (también en los estados compuestos). Para ello, primero haremos clic en los iconos correspondientes y luego clic en el diagrama, en la posición en la que queramos insertarlos. Para añadirles un nombre que los identifique, haremos doble clic sobre ellos, con lo que nos aparecerá la siguiente ventana:

Introduciremos el nombre que queramos en el campo “name” y confirmaremos los cambios haciendo clic sobre el botón “Close”. El nombre se añadirá al diagrama de forma automática.


P

ágina

31

El resto de los elementos los introduciremos de la misma forma. Cabe destacar un tipo de elemento especial, que son los estados compuestos. Los estados compuestos podríamos considerarlos como subdiagramas de estado que se incluyen en un StateChart . Para crear un estado compuesto (en el ejemplo se incluye uno), simplemente lo crearemos como un elemento normal del diagrama, sólo que dentro de este podremos insertar nuevos elementos, como por ejemplo estados, flujos, agregaciones de flujos, ... Todo estado compuesto posee uno o más estados iniciales y uno o más estados finales; y se relacionará con otros elementos del diagrama como si de un elemento básico se tratara.

Una vez hayamos incluido y nombrado todos los elementos que formarán parte del diagrama de estado, tendremos que incluir todas las relaciones, que representarán el posible cambio de un estado a otro. Para ello, seguiremos el mismo proceso que hemos seguido hasta el momento: 1. haremos clic izquierdo sobre el elemento origen del flujo 2. cuando aparezca el icono de la asociaci ón a su derecha, haremos clic sobre él y lo arrastraremos hacia el elemento que será el extremo final de la misma.


P

ágina

32

Repetiremos el proceso para cada una de las asociaciones que queramos establecer, siendo el resultado el siguiente:


P

ágina

33

Diagrama de Actividades Para crear un nuevo diagrama de este tipo, haremos clic con el botón derecho sobre la carpeta “Data” situada en el “ Containment Tree”, y seleccionaremos la opción “New Diagram -> Activity Diagram ”.


Acción

Llamada

Objeto

Flujo de control

Nodo inicial

Nodo final

Nodo decisión

Unión/división de flujo de control


P

ágina

34

Pasos para llevar a cabo la realización del diagrama La creación del diagrama de actividades es directa a partir de la barra de herramientas, salvo en un detalle: -

Si queremos que el flujo de control vaya desde una acci ón hacia otra acción, tendremos que hacer clic en el icono

-

de la barra de herramientas

Mientras que si queremos que sea un flujo de objetos, la relaci ón sea acciónobjeto, objeto-acción u objeto-objeto tendremos que hacer clic sobre

.

No obstante para mayor facilidad, si hacemos clic sobre una acción, en la parte derecha de la acción nos aparecerán los posibles elementos que pueden hacer referencia, al igual que si se hace clic sobre un objeto: Acción:

Objeto:

Realizamos un diagrama de actividades de ejemplo:


P

ágina

35

Generar Código Para generar código seguiremos los siguientes pasos: 1. en el men ú correspondiente a las opciones de código, seleccionaremos la opción “Generate”, y nos aparecerá el diálogo de “Opciones de generación de código”, mostrado en la siguiente imagen:

2. definiremos en este di álogo las opciones de la generación, seleccionando las correspondientes. Entre ellas podemos encontrar la opción “Output Directory”, correspondiente al directorio donde se guardarán los ficheros generados. 3. haremos clic en el bot ón OK. 4. si queremos modificar el c ódigo generado, podemos utilizar la opción “Edit Source” en el menú correspondiente a las opciones de código.


P

ágina

36

Generar Informes Para generar informes seguiremos los siguientes pasos: 1. Seleccionaremos la opción del menú “Tools -> Report”, con lo que se nos abrirá el diálogo correspondiente con la elección de informe:

2. Pestaña “Template Management”. En el árbol que está situado a la derecha escogeremos la plantilla correspondiente al tipo de informe que queramos generar. En el campo “Description” aparecerá una descripción con las características más importantes de cada una de las plantillas que aparecen. 3. En la pesta ña “Select Packages” podremos escoger el ámbito que abarcará el informe que nos disponemos a generar. Para ello seleccionaremos los paquetes que estimemos conveniente, y la opción “Generate Recursively” si queremos activar una generación recursiva del informe.


P

ágina

37

4. En la pesta ña “Select Diagrams” seleccionaremos los diagramas que abarcará el informe.


P

ágina

38

5. Por último, en la pestaña “Outputs Options” seleccionaremos las opciones finales del informe, como por ejemplo el directorio de salida, formatos de salida, ...

6. seleccionaremos la opción “Generate”.


P

ágina

39

Referencias Para la elaboración de esta guía hemos utilizado los recursos disponibles en la página web oficial de la herramienta Magic Draw (www.magicdraw.com), basándonos principalmente en: –

Documento “Magic Draw Tutorials”

–

Documento “Magic Draw User Manual” Ejemplos de diagramas

–

Para cualquier duda, omisión o error sobre esta guía, se recomienda la consulta de este material.


P

ágina

40

Alita Cursillo Completo de Ingenieria Del Software

Recommend Documents