proceso ingenieria del software - curso completo.pdf

Examen 2010/11-2

Assignatura Codi Data Hora inici

Enginyeria del programari 05.060 11/06/2011 09:00

Pàgina 1 de 6

Ì05.060Â11Â06Â11ÂEXEÎ Ì05.060Â11Â06Â11ÂEXEÎ Ì05.060Â11Â06Â11ÂEXEÎ Ì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? NO Quant? -

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

-

Enunciats

Espai grapa

Examen 2010/11-2



Pàgina 2 de 6

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

Examen 2010/11-2



Pàgina 3 de 6

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.

Examen 2010/11-2



Pàgina 4 de 6

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.

Examen 2010/11-2



Pàgina 5 de 6

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.

Examen 2010/11-2



Pàgina 6 de 6

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.

Examen 2010/11-2



Pàgina 1 de 6

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

05.060 18 06 11 EX





matriculat.







Cap




-

Enunciats

Espai grapa

Examen 2010/11-2



Pàgina 2 de 6

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

Examen 2010/11-2



Pàgina 3 de 6

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ó.

Examen 2010/11-2



Pàgina 4 de 6

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.

Examen 2010/11-2



Pàgina 5 de 6

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.

Examen 2010/11-2



Pàgina 6 de 6

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é.

Examen 2010/11-2



Pàgina 1 de 6

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

05.060 22 06 11 EX





matriculat.







Cap




-

Enunciats

Espai grapa

Examen 2010/11-2



Pàgina 2 de 6

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

Examen 2010/11-2



Pàgina 3 de 6

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.

Examen 2010/11-2



Pàgina 4 de 6

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.

Examen 2010/11-2



Pàgina 5 de 6

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.

Examen 2010/11-2



Pàgina 6 de 6

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.

Ingeniería del software

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE OO

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 (aunque hay copias de software usados por millones de personas, la producción en serie no nos interesa y 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

El ciclo de vida del software lo constituyen las etapas que preceden, y las que siguen a la etapa de programación. Existen varios ciclos de vida distintos, con

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

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

Ciclo de vida clásico

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

primera la reutilización de software de manera significativa, con lo que mejoramos la productividad y calidad a la que hacíamos referencia en el primer

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

TEMA

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 Group) se creó en 1989 para fomentar el uso

de la tecnología orientada a objetos e impulsar la generación de 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

estos, y que se hace siempre. Este diagrama muestra la estructura estática de

clases en 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

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

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

Ejemplo de clase e interfaz

Dos formas de representar

un mismo paquete


TEMA

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 que podemos encontrar son: público (+), protegido (#), privado (-) y dentro del 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: 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

La herencia presupone que existen dos clases, de las cuales una es la superclase y la otra la subclase. Esta subclase comprende un conjunto de los

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

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 así vehiculosde2ruedas se convierte en una clase abstracta de la cual no se

pueden crear (instanciar) directamente 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

Especificación de una clase

Herencia por especialización

Herencia por generalización


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 interfaz no es una clase, pero equivale a una clase abstracta sin

atributos y con todas sus operaciones diferidas. Puede las interfaces 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.

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

asociación tiene asociada una cardinalidad. Estudiamos los 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

empresa. La cardinalidad 0..1 nos indica que una persona

puede estar en 0 o en 1 empresa (nada de tener dos trabajos) y 1..* implica que toda empresa, al menos tiene

un empleado. Asociaciones reflexivas: 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

Interfaz Comparable

Instanciación

Asociaciones

Asociación binaria

Asociación reflexiva

Asociación ternaria


TEMA

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

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

categoría laboral, puede haber un número cualquiera de empleados (incluído 0). Esto lo podemos categorizar como 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

diferentes significados: acoplamiento-piezas (una máquina y sus piezas, un circuito eléctrico y sus componentes); continente-contenido (avión y

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

Clases asociativas

Asociaciones calificadas

Asociaciones alternativas

Asociaciones derivadas

Clases asociativas

Agregaciones

Composiciones


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: Son restricciones que deben cumplirse antes de la ejecución

de una operación.

Postcondiciones: Deben cumplirse al acabar la ejecución de una operación.

Invariantes: Deben cumplirse en todo momento.

Comentario


TEMA

TEMA 3 UML2: EL MODELO DINÁMICO Y 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: Es una situación determinada dentro de la vida de un objeto; eso sí,

un estado no corresponde a un instante de tiempo, sino que dependerá de que

se cumpla alguna condición o se produzca un acontecimiento. Transición simple: Consiste en que el objeto para de un estado (origen) 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 clave defer como primera acción si el acontecimiento es diferido.

El envío presenta la 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.

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

Diagrama de estado


Pueden existir transiciones complejas dado que un 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.

Un estado compuesto es aquella en la que existen

subestados, cada uno de los cuales, a su vez, puede 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 de todas las secuencias; mientras que si sale, es como si la

transición tuviera como estados de origen todos los estados finales de todas las 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ón el con el sistema software considerado, podemos decir que un actor es la visión que el software tiene de una entidad exterior. Para que un actor sea

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:

Transiciones complejas

Estados compuestos


TEMA

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.

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 mediante elipses de

trazo continuo. A veces todas las elipses se 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

rectángulos superpuestos y necesitan dos mensajes para realizar una operación en casa uno de sus objetos: uno sirve para seleccionar el conjunto de enlaces de 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.

Ejemplo de casos de uso y actores

Ejemplo 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 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 de secuencia.

Cláusula de condición: 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.

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

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 de los mensajes; sí se pueden indicar los mensajes de

retorno al final de una activación en forma de 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 colaboración

Ejemplo de diagrama de secuencias


TEMA

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 la imagen lateral.

Estados de flujo de objeto: 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 de control: Representan el envío de una señal al acabar un estado de

acción y su recepción en otro como entrada. Puede haber bifurcaciones y

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 físicos que hay que tiempo de ejecución, de compilación o de desarrollo, y

tienen una interfaz propia y bien definida. Pueden ser códigos fuente

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.

Ejemplo de diagrama de actividades

Diagrama de componentes


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

(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 memoria y capacidad de

proceso, pueden ser tanto ordenadores como 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.

Ejemplo de diagrama de despliegue


TEMA

TEMA 4 RECOGIDA Y DOCUMENTACIÓN DE REQUISITOS

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 son la información de partida para desarrollar el software, es decir, son el

pie que da entrada a la siguiente etapa.

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

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


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 interpretación. Por otro lato también está la documentación formal que

consiste en un diagrama de los casos de uso que 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

TEMA 5 ANÁLISIS ORIENTADO A OBJETOS

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ía no tenemos.

Identificar las clases 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 (pocas conexiones entre elementos de paquetes diferentes). A su

vez este paquete de análisis se divide en paquetes de servicio, es decir, por 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

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.


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.

Uno de los problemas que se da es el identificar las clases de entidades,

es importante hacerlo correctamente porque la mayoría pasarán a 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 que tienen un valor compartido por varios objetos (atributos de clase); los atributos no aplicables a todos los objetos de 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); no tiene sentido que una superclase abstracta tenga sólo una subclase, en este caso 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


TEMA

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

de la descripción textual de los casos de uso. Más directamente lo hacen las clases de frontera, más indirecta las clases de control, y las entidades muchas veces 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 de usabilidad.

Lista de las clases frontera

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 análisis describe las funciones que tiene que desempeñar el software

(plantea el problema) mientras que las etapas siguientes deben buscar 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 forma y con el mismo estilo.

Si se reutiliza un buen fragmento de código, será mucho más difícil que se

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 del usuario

8. Diseño de los subsistemas


TEMA

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 patrones, pero no al revés. Los patrones son 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 ha hecho en la etapa de análisis, y se consideran por

separado las clases de frontera, de entidades y 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 diseñan los casos de uso, y una vez acabado ello, debemos hacer una revisión

del diagrama obtenido. La revisión del diagrama obtenido (que suele 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.


TEMA

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 las

operaciones implícitas: 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 sus operaciones bien definidas. Pues es ahora cuando hay que revisarlo para que sea coherente; es decir, los atributos y

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 un sistema de almacenamiento permanente y también lógicamente debe poder ser leído. Existen tres 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

Supresión de la herencia múltiple


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 una solución portable a otro sistema distinto. Gestor de disco para cada clase persistente: Este 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 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

Supresión de la herencia

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

…


TEMA

a objetos de una clase sustituta. La clase original 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 al usuario y no a nosotros que lo diseñamos.

Familiaridad para el usuario; utilizando 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 compuestos

distribuidos: DCOM

6. Desarrollo del software distribuido


TEMA

En la Arquitectura de tres 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

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 entre los clientes y los

servidores y por este motivo 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.

El procesamiento de las peticiones según la

imagen 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.

Supresión de la herencia múltiple


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 para convertir un objeto en un stream

(externalizarlo) o justo lo congtrario (internalizarlo).

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.


TEMA

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

dentro de su ubicación original 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

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

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:



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.



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



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 componentes de proceso: • Recogida de requisitos (requirement capture), • 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 diagrama de clases y objetos, puede servir tanto en el análisis como en el diseño. 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.



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 la tecnología de objetos e impulsar la introducción de software orientado a objetos que ofrezca reusabilidad, portabilidad 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.



TEMA – 2 EL MODELO ESTÁTICO UML, TRES MODELOS DE DIAGRAMAS 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



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 “/”.



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.



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 (<<realizes>>) 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 (<<uses>>):



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 lugar 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:



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:



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.



• 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.



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 modelo 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ínea continua:

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



Línea discontinua:

Punta triangular vacía: la clase implementa la interfaz (<<realizes>>). Punta abierta: una clase tiene relación de dependencia respecto a la otra (<<uses>>). 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.



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 diagramas de interacción:

3.1) Diagrama de colaboración 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



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 <<extend>>, 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 <<includes>>, 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):



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.



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:



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 origen) a otro (estado de destino), que podría volver a ser el mismo:

En el caso más general, este paso comienza cuando se produce un acontecimiento determinado y al mismo tiempo se 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 origen.

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 origen, 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



• 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, cuando se producen, pueden provocar transiciones de un estado a otro en objetos e interacciones y/o la ejecución de determinadas acciones. Están 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”



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



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”:



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]).



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.



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



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):



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 tanto 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.



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 (Branch): Una ramificación ocurre cuando existe la posiblidad que

ocurra más de una transición (o una u otra) al terminar determinada actividad. 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):



• 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.



• 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,



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.



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.



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.


¿Qué son las herramientas CASE?

Solución:

Módulo 1, apartado 4.



Las 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.


Explicar los inconvenientes del Ciclo de Vida en Cascada



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.


Qué grandes fases se identifican en el modelo RUP (Rational Unified Process)?

Descríbalas brevemente.

Solución:



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)


Parecidos y diferencias entre el Ciclo de Vida con Prototipos y el Ciclo de vida de

la Programación Exploratoria.



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.


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)




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”



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.


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:



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”


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



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.


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



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.


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.



- 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.


Explique en qué consisten los ciclos de vida iterativos e incrementales y cuales son

los motivos que los originan.

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 originan “el ciclo de vida iterativo e incremental son los

siguiente:



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.


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



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 objetos:

- 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)


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.



- 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)


Exposa en unes 15 línies com a màxim els problemes de qualitat i productivitat en

l’enginyeria del programari.



Enumera i descriu en unes 15 línies com a màxim les fases del cicle de vida clàssic.



¿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



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)


Explica cuáles son los principales inconvenientes del ciclo de vida clásico y cómo se

resuelven:


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

Seminario de Magic Draw

Miguel Ángel Orenes FernándezPedro Luis Mateo Navarro

______________________________________________________________________Guía de MagicDraw Página 1

ÍndiceObjetivos ...........................................................................................................................3Consejos para el uso de esta guía......................................................................................4Desarrollo..........................................................................................................................5

El proyecto de Magic Draw..........................................................................................5Crear un proyecto nuevo...............................................................................................5

Diagramas UML................................................................................................................6Diagrama de Casos de Uso...........................................................................................6

Elementos más importantes de este tipo de diagrama..............................................6Pasos para llevar a cabo la realización del diagrama...............................................7

Diagrama de Clases....................................................................................................10Elementos más importantes de este tipo de diagrama............................................10Pasos para llevar a cabo la realización del diagrama.............................................11

Modelo conceptual......................................................................................................13Elementos más importantes de este tipo de diagrama............................................13Pasos para llevar a cabo la realización del diagrama.............................................14

Diagrama de Secuencia...............................................................................................17Elementos más importantes de este tipo de diagrama............................................17Pasos para llevar a cabo la realización del diagrama.............................................19

Diagrama de Colaboración.........................................................................................25Elementos más importantes de este tipo de diagrama............................................25Pasos para llevar a cabo la realización del diagrama.............................................26

Diagrama de Estados..................................................................................................29Elementos más importantes de este tipo de diagrama............................................29Pasos para llevar a cabo la realización del diagrama.............................................31

Diagrama de Actividades............................................................................................34Elementos más importantes de este tipo de diagrama............................................34Pasos para llevar a cabo la realización del diagrama.............................................35

Generar Código...............................................................................................................36Generar Informes.............................................................................................................37Referencias......................................................................................................................40


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


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.


Desarrollo

El proyecto de Magic DrawToda 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 nuevoPara 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.


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


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


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:


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.


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



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”


Ejemplo de diagrama de clases:


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



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.


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.


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:


Diagrama de SecuenciaPara 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


Mensaje Diagonal



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 :


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:


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


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.


La ventana de argumentos quedará de la siguiente manera:

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


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:


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



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:


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:


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:


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


Autotransición

Unión/división de transiciones



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.


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 flujo2. 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.


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


Diagrama de ActividadesPara 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


Pasos para llevar a cabo la realización del diagramaLa 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ón

objeto, objetoacción u objetoobjeto 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:


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.


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.


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


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”.


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.


http://www.magicdraw.com/

proceso ingenieria del software - curso completo.pdf

Documents