Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ven para definir estados incorrectos de los datos del software. Podemos ver las
restricciones como una condición booleana que tiene que ser cierta siempre.
Cuando una de estas condiciones se convierte en falsa quiere decir que hay un
error en los datos del sistema. Un ejemplo de restricción sería “todos los produc-
tos tendrán un precio >5”. En este caso, cada vez que damos de alta (o actuali-
zamos) un producto de forma que su nuevo precio sea inferior a cinco el soft-
ware tiene que detectarlo y avisar al usuario del error. Fijaos en que la multipli-
cidad de las asociaciones es también un tipo de restricción (por ej. definen el
número máximo y mínimo de relaciones entre clientes y ventas). En general,
sin embargo, las restricciones no se pueden definir gráficamente sino que hay
que hacerlo textualmente, ya sea en lenguaje natural o en OCL.
nueva iteración sobre el diagrama de clases anterior con el fin de incluir las nue-
vas clases.
Además, para cada mensaje que aparezca en este diagrama hay que definir
una nueva operación dentro de la clase correspondiente (es decir, la que recibe
el mensaje). Esta operación sería la encargada de procesar la petición del men-
saje. Se tiene que especificar el comportamiento de todas las operaciones (es
decir, “qué” tiene que hacer la operación). Eso podemos definirlo descriptiva-
mente en lenguaje natural, especificarlo formalmente con contractos en OCL o
escribiendo directamente cómo tendría que ser el código de la operación.
5. Tendencias
5.3. Reutilización
Copyright © 2013. Editorial UOC. All rights reserved.
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”.
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).
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.
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.
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.
de los datos del sistema). En muchos casos, se opta también por buscar directa-
mente a un profesional con el perfil de analista/programador. En estos casos
se espera que la misma persona sea capaz de realizar las tareas de analista y de
programador. Normalmente, en estos casos se indica ya explícitamente cuál es
el lenguaje con el que se implementará el sistema, por ej: “Analista/programa-
dor en Java EE”, ya que conocer el lenguaje de implementación elegido es un
requisito indispensable para poder ocupar este perfil.
Para concluir, la última opción es ser jefe de proyectos. El trabajo principal
de un jefe de proyectos es planificar el proyecto de desarrollo y gestionar el
grupo humano que tiene a sus órdenes con el fin de asegurar que el desarrollo
cumple los plazos establecidos con la máxima calidad posible. Es el responsable
de calcular y fijar estos plazos18 en función de la complejidad de los requisitos
expresados por el cliente y de los recursos de que disponga.
Cada paso en la evolución laboral nos aleja más de las tareas puramente tec-
nológicas. Una alternativa es evolucionar hacia la especialización máxima en
una tecnología determinada. Por ejemplo, se podría ser un experto en tecnolo-
gías Java EE, de forma que cualquier proyecto de desarrollo que tuviera que uti-
lizar Java EE pudiera requerir nuestro conocimiento a la hora de decidir qué
arquitectura sería la mejor para el proyecto, qué tecnologías Java EE
Copyright © 2013. Editorial UOC. All rights reserved.
18. Desgraciadamente, es frecuente que esta decisión se vea parcialmente condicionada por otras
áreas de la misma empresa, que quieren asegurar que el cliente acabe aceptando la propuesta, a ries-
go de tener dificultades posteriores para poder cumplir los plazos.
Bibliografía
Warmer, J.; Kleppe, A. The Object Constraint Language: Getting Your Models
Ready for MDA, Addison-Wesley
Cabot, J.; Guitart, I. (coordinadores); Fernández, J.; Pradel, J.; Raya, J.A.
(autors) (2005). Enginyeria del programari orientat a l'objecte. Fundació per a la
Universitat Oberta de Catalunya.
6LOHKDJXVWDGRHVWHFDStWXORSXHGHDGTXLULUHOUHVWRGHODREUD
HQODVSODWDIRUPDVKDELWXDOHVJRRJOH3OD\&DVDGHO/LEUR&DVDOLQL
/LEHUGUDFH/LEUR'DZVRQHUDHQXQIXWXURSUy[LPR$PD]RQHWF