Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
5. Tendencias
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 190 Escaneando la Informática
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 191 Ingeniería del software
5.3. Reutilización
Copyright © 2013. Editorial UOC. All rights reserved.
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 192 Escaneando la Informática
de clases especificado en UML tiene que ser ante todo sintácticamente correcto.
Eso quiere decir que tiene que cumplir con las reglas de “escritura” que define
el lenguaje UML, tanto con respecto a los símbolos utilizados como con respec-
to a las relaciones entre estos símbolos (a modo de ejemplo, una de las reglas
prohíbe que una clase sea subclase de ella misma).
Sin embargo, eso no es suficiente para asegurar que el modelo es correcto;
hay que hacer otros tipos de comprobaciones. Por ejemplo, el diagrama de la
figura 8 es perfecto sintácticamente hablando, pero no es correcto. La clase
Persona tiene una relación consigo misma, donde dice que toda persona tiene
como mínimo un padre/madre y que puede tener cero o más hijos. ¿Cuál es el
problema? Fijaos qué pasa si intentamos dar de alta a la persona “Georgina”.
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 193 Ingeniería del software
Como toda persona tiene como mínimo un padre/madre, nos vemos obligados
a entrar también a Julia que es la madre de la Georgina. Pero, claro, al entrar a
Julia nos vemos obligados a entrar también a la madre de Julia... Para evitar este
elemento recursivo infinito tenemos que cambiar el diagrama de clases con el
fin de permitir que dentro de nuestro sistema haya personas sin padre (es decir,
personas de quienes, por el motivo que sea, no nos interesa saber quiénes son
sus padres). Hay que tener en cuenta también estos posibles errores a la hora de
verificar un modelo, de lo contrario cuando lo hayamos implementado y empe-
cemos a ejecutar el software resultante nos podemos encontrar con sorpresas
desagradables (y entonces ya será más costoso arreglar los errores).
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 194 Escaneando la Informática
14. Ejemplos de métodos ágiles, aparte de XP, son: SCRUM, Dyanmic Systems Development
Method, Crystal Methodologies, Feature- Driven Development y Adaptive software Development.
15. El Agile Manifesto es un conjunto de principios y valores que tienen que cumplir todos los
métodos “ágiles” y que surgieron a raíz de una reunión que tuvieron los principales representantes
de cada método en el año 2001.
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 195 Ingeniería del software
Otro aspecto importante del XP es que defiende que de las cuatro variables
que pueden definir un proyecto (coste en inversión y recursos, tiempo, calidad
y conjunto de funcionalidades) sólo tres las puede escoger el cliente y/o el jefe
de proyectos. La cuarta es responsabilidad del equipo de desarrollo (si se mar-
can los recursos, la calidad y las funcionalidades, el equipo de desarrollo indica-
rá el tiempo que tardará en desarrollar aquellas funcionalidades con los recur-
sos y los plazos previstos).
El UML es un lenguaje generalista, es decir, está pensado para ser útil inde-
pendientemente de cuál sea el dominio del sistema de software que tenemos que
construir (comercios, bancos, asseguradores,…). Precisamente por éstos motivo,
como ya hemos comentado anteriormente, el UML es el lenguaje de modeliza-
ción más usado, con diferencia, hoy en día. De todos modos, esta misma voca-
ción generalista hace del UML un lenguaje muy amplio y complejo de dominar
en la su totalidad. Eso ha hecho que ciertas comunidades que desarrollan soft-
ware para dominios muy concretos, como por ejemplo el sector de la automo-
ción, prefieran desarrollar y utilizar lenguajes de modelización más pequeños y
mejor adaptados a los conceptos y semántica de aquel dominio.16 Este tipo de
lenguajes son los que denominamos lenguajes específicos de dominio (domain-
specific languages en inglés).
La ventaja de este tipo de lenguajes es que permiten modelar utilizando direc-
tamente la terminología y los conceptos utilizados en aquel dominio concreto
cosa que facilita el trabajo de los analistas y diseñadores y también la compren-
Copyright © 2013. Editorial UOC. All rights reserved.
sión de los modelos por parte del cliente. El inconveniente es, obviamente, el
coste de crear estos nuevos lenguajes (y las herramientas por manipularlos) ya
que en la gran mayoría de los casos estos lenguajes no están estandarizados sino
que se tienen que diseñar partiendo de cero. Por suerte, tecnologías actuales
como EMF (Eclipse Modeling Framework) y GMF (Graphical Modeling Framework)
facilitan la definición de lenguajes específicos de dominio y la creación automá-
tica de entornos de modelización para los mismos.
16. El propio UML también ofrece la posibilidad de adaptar su semántica a dominios específicos
mediante el uso de profilas pero sólo de una forma limitada.
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.
© Editorial UOC 196 Escaneando la Informática
No hay ninguna regla de oro que permita decidir cuándo es mejor utilizar un
lenguaje reconocido pero generalista como el UML y cuándo es mejor crearse un
mismo un lenguaje más adaptado a nuestras propias necesidades. Aconsejaría
utilizar el UML siempre que sea posible y sólo cuando realmente el UML no se
adapte bien al dominio para el cual tenemos que desarrollar el software en cues-
tión tomar la decisión de adoptar un lenguaje específico de dominio.
6. Salidas profesionales
Las perspectivas laborales de los expertos en IS son mucho buenas.17 Los dife-
rentes perfiles profesionales coinciden básicamente con las diferentes fases del
ciclo de vida del desarrollo del software (programador, analista, jefe de proyec-
tos...). La evolución laboral de un/a ingeniero/a de software dentro de la empre-
sa se acostumbra a producir en el sentido inverso al orden de las correspondien-
tes etapas dentro del ciclo de vida del desarrollo del software.
Así pues, se acostumbra a empezar trabajando como programador. Dada una
especificación parcial del sistema que tiene que desarrollarse, el programador es
el encargado de implementar aquella parte del sistema utilizando el lenguaje de
programación y el tipo de plataforma escogido.
El responsable de definir esta especificación se llama analista. A partir de un
conjunto de requisitos dados por el cliente, el analista define qué tiene que
hacer el sistema (qué funcionalidad tiene que ofrecer, qué información tiene
Copyright © 2013. Editorial UOC. All rights reserved.
17. El ingeniero de software es la profesión más valorada en los Estados Unidos, según la revista
Money. http://money.cnn.com/magazines/moneymag/bestjobs/. Visitada en noviembre de 2006.
Cabot, Sagrera, Jordi. <i>Ingeniería del software</i>, Editorial UOC, 2013. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3219169.
Created from unadsp on 2019-08-25 15:08:29.