Ingeniería Del Software PDF

© Editorial UOC 189 Ingeniería del software
5. Tendencias
Para acabar el capítulo presentamos una serie de técnicas y métodos que

todavía no tienen un uso generalizado en la industria de desarrollo del software
pero que, en nuestra opinión, adquirirán cada vez un mayor protagonismo en
los próximos años. El horizonte temporal varía para cada propuesta; algunas
propuestas están ya lo bastante maduras mientras que otras todavía están
actualmente en fase de investigación.
En concreto presentaremos las propuestas siguientes: desarrollo de software
dirigido por modelos, ingeniería web, reutilización, verificación y validación de
modelos y métodos ágiles. Las diferentes propuestas se pueden combinar entre
sí, lo cual maximiza sus ventajas. Por ejemplo, se podría partir de un modelo
UML verificado y validado a la hora de seguir un proceso de desarrollo dirigido
por modelos con vistas a generar un software basado en web.
5.1. Ingeniería web
La ingeniería web se puede definir como la especialización de la IS para el

caso específico del desarrollo de software basado en tecnologías web. Por lo
tanto, la ingeniería web no es un nuevo paradigma o un nuevo tipo de ingenie-
ría. Los métodos de desarrollo web toman (y especializan) aquellas técnicas de
la IS más útiles para el caso concreto del software web.12
Por ejemplo, aparte de otros diagramas (como el diagrama de clases, el de
casos de uso, etc., vistos en el punto anterior), todos estos métodos utilizan lo
Copyright © 2013. Editorial UOC. All rights reserved.
que denominamos modelo de navegación. Este modelo permite representar las

diferentes páginas webs que forman el software web, el contenido de cada pági-
na (qué datos muestra y cómo los muestra), los enlaces entre ellas, así como (en
algunos de los métodos) las operaciones que se tienen que “ejecutar” cuando el
usuario navega de una página a otra. La figura 7 muestra una parte del posible
modelo de navegación (especificado usando el lenguaje WebML) para el softwa-
12. En el año 2000 un grupo de expertos se reunió en la 22 International Conference on software

Engineering para plantear los temas de futuro de la ingeniería del software. Sus trabajos se pueden
encontrar en: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/future.html (visitada en noviembre
de 2006). Muchos de ellos todavía son plenamente vigentes hoy día. Ejemplos de métodos web son:
WebML, OO-Method, OOH, UWE, OOHDM o Strudel.
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
re de la tienda VamosAComprar si el tendero pidiera la opción de permitir com-

pras por Internet. La página login permite a los clientes registrarse en el sistema.
A partir de ahí el cliente puede ir a la página NuevaVenta. Una vez entrados los
datos necesarios para dar de alta la venta (por ejemplo el código y la fecha,
suponiendo que no se generen automáticamente), el usuario navega hasta la
página AñadirProducto. Durante la navegación se crea el nuevo objeto venta
(operación InsertVenta) y la relación entre esta venta y el cliente
(InsertHaComprado). Desde la página AñadirProducto el cliente puede ir indican-
do los productos que quiere comprar (cada vez que añade uno, se crea el víncu-
lo entre la venta y el producto, operación InsertIncluye, y se vuelve a la misma
página para añadir otra nuevo si es necesario). Cuando todos los productos han
sido añadidos el cliente ya puede dirigirse a la página Checkout.
Algunos de estos métodos utilizan la notación UML (con algunas extensio-
nes) mientras que otros utilizan su propia notación.
Figura 7. Ejemplo de modelo de navegación

5.2. Desarrollo de software dirigido por modelos
El desarrollo de software dirigido por modelos13 pretende utilizar la informa-

ción contenida en los modelos especificados durante las fases de análisis (espe-
cialmente) y de diseño con el fin de automatizar todo lo posible la fase de codi-
13. Model-driven development (MDD), en inglés.
ficación del software, evitando así la necesidad de invertir esfuerzos en su pro-

gramación final (con lo que además se evitan posibles errores introducidos
involuntariamente por los programadores en esta fase). Imaginad las ventajas
de poder generar automáticamente el software de la tienda VamosAComprar a
partir de diagramas UML como los vistos en la sección anterior.
Esta posibilidad es ampliamente utilizada dentro de la comunidad de bases
de datos con el fin de generar automáticamente las tablas de la base de datos a
partir de, por ejemplo, un diagrama de clases UML, pero no ha sido hasta los
últimos años cuando este tema ha tomado vuelo dentro de la IS. A modo de
ejemplo, actualmente todas las herramientas CASE se anuncian mencionando
sus avanzadas capacidades de generación automática de código. Incluso el OMG
ha presentado el estándar MDA (Model-Driven Architecture) como marco general
para estos tipos de métodos. El MDA propone que a partir de los modelos de la
fase de análisis se generen (semiautomáticamente) los modelos de la fase de
diseño y que a partir de éstos se genere directamente la implementación de la
aplicación.
Aunque en la parte estática del software (los datos), el mecanismo de genera-
ción automática está más o menos establecido (es fácil imaginar qué clases Java
serían necesarias para implementar el diagrama de clases del punto 3.2.2, sobre
todo si obviamos la parte textual del diagrama), en la parte dinámica (el com-
portamiento) todavía no está del todo claro cómo se tiene que llevar a cabo y/o
hasta qué punto es posible hacerlo.
5.3. Reutilización
Una de las supuestas ventajas de la programación orientada a objetos (el

paradigma imperante en la actualidad) es la facilidad de reutilización del códi-
go, con el ahorro de tiempo (¡y de dinero!) que eso comporta. Sin embargo,
todavía no se ha conseguido que la reutilización funcione a gran escala. Con el
incremento de madurez del área de IS están surgiendo una serie de propuestas
que pretenden mejorar el porcentaje de reutilización en el desarrollo de nuevos
proyectos.
Por una parte hay propuestas para la reutilización del conocimiento median-
te el uso de patrones. Los patrones son soluciones genéricas a problemas habi-
tuales en el desarrollo de software. Por lo tanto, una vez nos encontramos el
problema, en vez de intentar solucionarlo nosotros mismos, podemos ver si
alguien que se ha encontrado con él anteriormente ya ha propuesto cómo solu-

cionarlo (y si se puede adaptar su solución a nuestro contexto). Hay patrones
para cualquiera de las actividades (y fases) del proceso de desarrollo.
Otra opción es usar métodos de desarrollo basados en componentes. Una
vez hecho el análisis de requisitos del sistema, estos métodos proponen mirar si
alguna de las partes del sistema puede estar ya desarrollada (por ejemplo, por
alguna empresa externa). La idea es ir hacia la creación de mercados de compo-
nentes, en los que una empresa pueda ir a buscar el componente que necesite.
Este tipo de componentes se llaman componentes COTS (commercial off-the-
shelf). Con el fin de generalizar este tipo de mercados, todavía hay que trabajar
en temas como por ejemplo asegurar la calidad de los componentes, cómo bus-
car los componentes adecuados y cómo integrarlos fácilmente con el resto del
sistema.
5.4. Verificación y validación
Debido a la creciente importancia de los diferentes modelos de análisis y

diseño en el desarrollo de software (por ejemplo, pueden servir para la genera-
ción automática de la implementación del sistema, como hemos comentado en
el punto 4.2), es cada vez más importante verificar y validar estos modelos.
La verificación de un modelo hace referencia al proceso por el cual se com-
prueba que el modelo cumple una serie de propiedades que permiten conside-
rarlo correcto. Un modelo es correcto si está especificado de forma coherente
con la notación que usa, si no tiene redundancias, si es consistente (no hay dos
partes del modelo que definen cosas contrarias), etc. Por ejemplo, un diagrama
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).
Figura 8. Ejemplo de modelo incorrecto
Muchas veces la verificación se lleva a cabo transformando el modelo UML

en un lenguaje formal y comprobando la corrección del modelo resultante de
la transformación utilizando técnicas (matemáticas y/o lógicas) propias del len-

guaje formal.
La validación consiste en comprobar que el modelo expresa realmente lo
que el cliente nos ha pedido (es decir, que realmente refleja sus necesidades).
Desgraciadamente, no hay una forma automática de validar un modelo ya que
es el cliente quien tiene que dar el visto bueno. Además, como el cliente proba-
blemente no será capaz de leer los modelos tampoco los puede validar directa-
mente. Las técnicas de validación más habituales incluyen algún tipo de simu-
lación o animación de los modelos, de manera que el cliente pueda hacerse una
idea de cómo se comportará el sistema una vez esté implementado. El cliente
valida indirectamente el modelo cuando valida la simulación.
5.5. Métodos de desarrollo ágiles
Para determinados proyectos, la rigidez y la meticulosidad impuesta por los

métodos de desarrollo actuales (como el UP) puede ser excesiva; es posible que
no sea realmente necesario hacer todas las actividades propuestas y/o con el
nivel de detalle requerido por el método.
Como reacción a estos métodos estrictos han surgido los métodos ágiles. Los
métodos ágiles14 se basan en los valores expresados en el Agile Manifesto:15 Se
valoran más 1. los individuos y sus interacciones que el proceso de desarrollo y
las herramientas; 2. el desarrollo de un software que realmente funcione que una
buena documentación; 3. la colaboración con el cliente que la elaboración de
un contrato; y 4. la capacidad de responder a los cambios que el seguimiento de
una planificación. Como veis, estos principios intentan romper con la rigidez
de los métodos “tradicionales” y dar una respuesta más rápida (más “ágil”) a las
necesidades cambiantes del entorno.
De acuerdo con estos principios, cada método ágil propone una serie de téc-
nicas que se pueden aplicar. Por ejemplo, el XP (eXtreme Programming), sin duda
el método ágil más popular, propone la aplicación, entre otras, de las siguientes
técnicas:
– Diseño simple. Hay que utilizar el diseño más simple posible mientras solu-
cione el problema.
– Pruebas intensivas. Las pruebas se escriben antes del propio código. Eso
obliga a los programadores a pensar en lo que puede fallar antes de escri-
bir el código. Además, se verifica continua y automáticamente que el códi-
go supera todas las pruebas definidas hasta después de cada cambio.
– Refactorización. Mejora continua del código. Incluso el código que ya se ha
considerado bueno se tiene que mejorar si vemos la oportunidad de ello. A

la larga eso mejora la calidad de todo el sistema de software.
– Programación por parejas. Se consigue una mejor calidad si siempre se traba-
ja por parejas (uno de los miembros de la pareja escribe el código y el otro revi-
sa lo que se va escribiendo; los papeles se intercambian al cabo de un rato).
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).
5.6 Lenguajes específicos de dominio
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-
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
que gestionar...) con el fin de dar respuesta a estos requisitos. Esta especifica-

ción se define usando el método y la notación escogidos (por ejemplo, UP
como método y UML como notación).
Es importante subrayar que la figura del diseñador no acostumbra a existir
como tal. Las tareas propias de la fase de diseño (adaptar el análisis a las capa-
cidades del lenguaje y la plataforma tecnológica con la que se quiere implemen-
tar el sistema) se asignan o bien al programador o bien al analista (o bien al
administrador de la base de datos para la parte que tiene que ver con la gestión
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.

Ingeniería Del Software PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ingeniería Del Software PDF

Transféré par

Droits d'auteur :

Formats disponibles

© Editorial UOC 189 Ingeniería del software

Para acabar el capítulo presentamos una serie de técnicas y métodos que

5.1. Ingeniería web

La ingeniería web se puede deﬁnir como la especialización de la IS para el

que denominamos modelo de navegación. Este modelo permite representar las

12. En el año 2000 un grupo de expertos se reunió en la 22 International Conference on software

re de la tienda VamosAComprar si el tendero pidiera la opción de permitir com-

Figura 7. Ejemplo de modelo de navegación

5.2. Desarrollo de software dirigido por modelos

El desarrollo de software dirigido por modelos13 pretende utilizar la informa-

13. Model-driven development (MDD), en inglés.

ﬁcación del software, evitando así la necesidad de invertir esfuerzos en su pro-

Una de las supuestas ventajas de la programación orientada a objetos (el

alguien que se ha encontrado con él anteriormente ya ha propuesto cómo solu-

5.4. Veriﬁcación y validación

Debido a la creciente importancia de los diferentes modelos de análisis y

Figura 8. Ejemplo de modelo incorrecto

Muchas veces la veriﬁcación se lleva a cabo transformando el modelo UML

la transformación utilizando técnicas (matemáticas y/o lógicas) propias del len-

5.5. Métodos de desarrollo ágiles

Para determinados proyectos, la rigidez y la meticulosidad impuesta por los

considerado bueno se tiene que mejorar si vemos la oportunidad de ello. A

5.6 Lenguajes especíﬁcos de dominio

que gestionar...) con el ﬁn de dar respuesta a estos requisitos. Esta especiﬁca-

Vous aimerez peut-être aussi