Métodos avanzados desarrollo software

Prof. Dr. Ricardo TESORIERO – Departamento de Sistemas Informáticos- Universidad de Castilla-La Mancha
[ricardo.tesoriero@uclm.es]
Métodos Avanzados de Desarrollo de Software
Asignatura Optativa de 4º Año
Grado en Informática
Departamento de Sistemas Informáticos
Universidad de Castilla-La Mancha
Métodos avanzados de
desarrollo de software
Tema I: Introducción

Índice
• ¿Por qué necesitamos nuevos métodos de desarrollo?
• ¿Qué se ha estado haciendo para mejorarlo?
• ¿Qué es una Arquitectura dirigida por modelos (ADM), del
inglés Model-driven Architecture (MDA)
El material que aquí se presenta está parcialmente basado en una traducción de:
Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA Distilled: Principles of Model-
Driven Architecture. Addison Wesley. 2004.

¿Por qué necesitamos nuevos
métodos de desarrollo de software?
• El software es caro [A]
• En US se gastan aprox. $ 250.000.000.000 en 175.000 proyectos
• Más del 30% de los proyectos son cancelados
• Más del 50% de los proyectos cuesta más del doble
• La demanda sigue subiendo, ya que los dispositivos tienen
• > Capacidades de comunicación
• > Capacidad de percepción (Sensores)
• Acelerómetros
• Cámaras infrarrojas
• Reconocimiento de voz
• De movimiento / gestos
• > Capacidades de Pantallas
• Táctiles y multi-táctiles
• > Diversidad de plataformas
• IOS
• MACOS
• Windows
• Linux
• Android
[A] Fuente Ovum (http://www.ovum.com) y el
Standish Group (http://www.standishgroup.com)

¿Qué ha sucedido durante los
últimos 50 años?
• Se ha elevado el nivel de abstracción de los lenguajes
• ASSEMBLER < C# ó Java
• Se ha elevado el nivel de re-uso en la construcción de sistemas
• Procedimientos / Funciones < Librerías, APIs, Servicios Web, etc.
movl $1, %eax
movl $2, %ebx
addl %eax, %ebx
a = 1;
b = 2;
b = a + b;

NIVEL DE ABSTRACCIÓN
Lenguaje de programación
Herramientas
Plataforma
Modelos
Evolución

Elevando el nivel de abstracción
Lenguajes de programación
• Las historia del desarrollo de software es una historia de
elevar el nivel de abstracción
• Programas cableados. Interruptores para ingresar
instrucciones … (0 y 1)
• Ensambladores Mnemonicos => 0 y 1 (Única plataforma)
• Lenguajes de programación
• FORTRAN (traducción de fórmulas)
• COBOL y C => portabilidad y programación estructurada
• + fácil de escribir, entender y mantener
• Smalltalk, C++, Eiffel y Java
• Orientados a objetos => datos y comportamiento en Clases y
Objetos

Herramientas
• A medida que se pasa de un lenguaje a otro, se incrementa el
nivel de abstracción en el que trabaja el desarrollador
C++ => C => ASM => Lenguaje Máquina => Hardware
• Para ello se necesitan herramientas
• Ensambladores, Pre-procesadores y compiladores
• ¿Cuál es el resultado de elevar el nivel de abstracción?
• Ocultar los detalles de las capas inferiores. Por ej. JMP -> “GOTO”
• Escribir en un lenguaje de alto nivel que luego es mapeado
automáticamente a uno de nivel más bajo

Independencia de la plataforma
• La independencia de la plataforma de software es análoga a la
de hardware
• Un lenguaje independiente de la plataforma de hardware
(Java o C) permite escribir una especificación que puede
ejecutarse en diferentes plataformas de hardware sin cambio.
• Un lenguaje independiente de la plataforma de software
permite escribir una especificación que puede ejecutarse en
diversas plataformas de software

Independencia de la
Plataforma de Software
• Pregunta:
• ¿Qué lenguaje conocemos para especificar software de manera
independiente de la plataforma de software?
• Respuesta
• UML!
• Por ejemplo:

Ejemplo
JavaScript - Mongoose
var mongoose = require('mongoose’);
var Schema = mongoose.Schema({
titulo:{type: String, required: true},
isbn:{type: String, required: true},
precio: {type: Number, required: true},
descripcion:{type: String, required: false},
iva:{type: Number, required: true, default: 21}
autores:{type: String, required: true},
});
module.exports = mongoose.model('Libro’, Schema);

Ejemplo
Java EE - JPA
package libreria;
import java.io.Serializable;
import java.lang.String;
import javax.persistence.*;
@Entity
public class Libro implements Serializable {
private String titulo;
public String getTitulo() {return this.titulo;}
public void setTitulo(String titulo){this.titulo = titulo;}
private String isbn;
public String getIsbn() {return this.isbn;}
public void setIsbn(String isbn) {this.isbn = isbn;}
private double precio;
public double getPrecio(){return this.precio;}
public void setPrecio(double precio){this.precio = precio;}
private String descripcion;
public String getDescripcion() {return this.descripcion;}
public void setDescripcion(String descripcion){this.descripcion =
descripcion;}
private double iva;
public double getIva(){return this.iva;}
public void setIva(double iva) {this.iva = iva;}
private String autores;
public String getAutores() {return this.autores;}
public void setAutores(String autores) {this.autores = autores;}
private static final long serialVersionUID = 1L;
public Libro() {super();}
}
UML

Evolución de la abstracción
Código
Ensamblador
Ensamblador
Sin
Plataforma
Código de
Máquina
1960s
Código Fuente
de Lenguaje de
Alto Nivel
Compilador
de Código
Fuente
Plataforma
de
Hardware
Código
Ensamblador
1980s
Modelo
Ejecutable
Compilador
de Modelos
Plataforma
de Software
Código Fuente
2000s
Figura basada en la presentada en [1].

NIVEL DE RE-USO
Evolución
Problemas del re-uso

Elevando el nivel de re-uso
• En los sistemas antiguos, la memoria era tan «cara» que a menudo era necesario ahorrarla
• Código In-line (código reusable)
•  contexto de uso => banderas
• Función => transforma entradas en salidas (no hay que preocuparse del estado) ej. Raíz
cuadrada
•  funciones que dependen de estados previos, ej. Stock de un libro
• Estructuras de datos compartidas (globales)
•  = que los códigos in-line (acceso no controlado => banderas)
•  cambios en la estructura revisión de todas las subrutinas
• Objetos (estructura + comportamiento)
•  re-uso a pequeña escala
• Abre el camino al re-uso de colecciones de objetos
• Componentes => re-uso de conjunto de objetos con un conjunto de interfaces definidas.
•  ¿Qué pasa si una interfaz cambia?
• Cambiar cada lugar en donde se usa la interfaz, testear el código, reintegrarlo y re-testear el
sistema.
•  Pequeño cambio en la interfaz => gran trabajo en el sistema

Evolución del nivel de re-uso
Modelos de Dominio
Componentes y frameworks
Objetos
Funciones
1970s 1980s 1990s 2000s
Figura basada en la presentada en [1].

Problemas de re-uso
• Caracterización
• El proyecto comienza con un entendimiento del problema
incompleto que es dividido entre varios equipos de desarrollo.
• Situación
• Los equipos comparten interfaces definidas que se enchufan
(plug) al final del proyecto
• Cuestión
• Hasta las mejores especificaciones de interfaces pueden ser mal
interpretadas
• Conclusión
• Así, componentes y frameworks no son usualmente (Plug &Play)
=> mucho tiempo en escribir el código pegamento (Glue Code)

Ejemplo
Arquitecturas multi-capa
Persistencia (Servidor de Bases de Datos)
Servicios Web (Servidor Web)
Interfaz de Usuario (Aplicación cliente)
Lógica de Negocios (Servidor Web / Bases de Datos)
MySQL SQLServer MongoDB
.NET JavaEE Node.JS
SOAP ReST XML-RPC
Web iOS Android
Experto 1
Experto 2
Experto 3
Experto 4

Ejemplo
Arquitecturas multi-capa
1. ¿Qué sucede si queremos la misma aplicación en distintas
plataformas cliente? Por ej. Android, iOS y Web
• 1 experto => 3 expertos diferentes
2. ¿Qué sucede si queremos soportar diferentes servicios Web?
• Por ej. ReST (aplicaciones B2C), SOAP (aplicaciones B2B) y XML-RPC
(aplicaciones legadas)
3. ¿Qué sucede si necesitamos soportar soluciones propietarias y
abiertas? Por ej. .NET, Node .JS o PHP
• 1 experto => 3 expertos diferentes
4. ¿Qué sucede si necesitamos soportar el acceso a datos con
distintos modelos de datos?
• No-Relacional (MongoDB)
• Relacional (MySQL y SQLServer, abierta y propietaria
respectivamente)

Elevando el nivel de re-uso
Solución: Modelos de dominio
• Se basa en la división del trabajo de áreas de interés (modelos
de dominio)
• Lógica de Negocios, Bases de datos, Interfaces de usuario, etc.
• Así las interfaces a nivel de reglas
• «Los datos persistentes de una clase se guardan en una tabla»
• «Las propiedades de tipo String se representan como campos de
texto en la Interfaz de usuario»
• Las reglas se aplican uniformemente => “Glue Code” puede
ser generado automáticamente

Modelos de dominio
Libro
titulo
precio
descripcion
iva
autores
isbn

Persistencia
Libro
titulo
precio
descripcion
iva
autores
isbn
CREATE TABLE Libro (
isbn VARCHAR(30) PRIMARY KEY,
title VARCHAR(30) NOT NULL,
descipcion VARCHAR(255),
autores VARCHAR(50) NOT NULL,
iva DECIMAL (4,2) NOT NULL,
precio DECIMAL(15,2) NOT NULL)

Servicios
Lógica de Negocios
var mongoose = require('mongoose’);
var Schema = mongoose.Schema({
titulo:{type: String, required: true},
isbn:{type: String, required: true},
precio: {type: Number, required: true},
descripcion:{type: String, required: false},
iva:{type: Number, required: true, default: 21}
autores:{type: String, required: true},
});
module.exports = mongoose.model('Libro’, Schema);
var express = require('express’);
var Libro = require('../model/libro’);
var router = express.Router();
router.get(‘/libros', function(req, res, next) {
return Libro.find({})
.then((result) => res.status(200).send(result))
.catch((err) => res.status(500).send(err));
} …

Presentación
<form>
<h2>Libro</h2><br>
<label>Isbn:</label><br>
<inputtype="TEXT"><br>
<label>Titulo:</label><br>
<label>Autores:</label><br>
<label>Descipcion:</label><br>
<textarearows="5"></textarea><br>
<label>Precio:</label><br>
<inputtype="NUMBER"><br>
<label>Iva:</label><br>
<inputtype="NUMBER"><br>
<inputtype="BUTTON"value="Save">
</form>

¿Cuál es el objetivo de una MDA?
• Enfatizar el re-uso
• Enfatizar la abstracción
REUSO + ABSTRACCIÓN
• Para conseguir “Interoperabilidad en tiempo de diseño”

INTEROPERABILIDAD
Evolución
Problemas del re-uso

Sistema
Interoperabilidad
en tiempo de diseño
• Situación
• Los sistemas re-implementan funcionalidad para
usar una tecnología mejor
• Los sistemas no pueden reusar las plataformas
porque están mezclados con la aplicación
• Estándares e Interoperabilidad ayudan
• Ejemplo
• Sistema de 2 aplicaciones (cliente y servidor)
• Cliente
• 3 plataformas => 3 aplicaciones
• Servidor
• 3 tecnologías de Servidor para la Lógica de
Negocios
• 3 tecnologías de Servicios Web por tecnología de
• 3 tecnologías de persistencia por cada tecnología
de Servidor
• Configuraciones
• Servidor: 3 x 3 x 3 = 27
• Cliente: 3 x 3 = 9
• Sistema: 27 + 9 = 36
Servidor de Bases de datos (Persistencia)
Servidor Web (Lógica de Negocios)
.NET NodeJS PHP
Servidor Web (Servicios Web)
SOAP ReST XML-RPC
Cliente (Interfaz de Usuario)
iOS Android Web

Sistema
Servidor de Bases de datos (Persistencia)
Servidor Web (Lógica de Negocios)
.NET NodeJS PHP
Servidor Web (Servicios Web)
SOAP ReST XML-RPC
Cliente (Interfaz de Usuario)
iOS Android Web
Interoperabilidad
en tiempo de diseño
• Solución
• Reuso independiente de capas
• “Glue Code” independiente del
contenido de las capas
• Bridges «Puentes» entre capas
expresados como “mapeos”
entre elementos de las capas
• Bridges interceptan las interfaces
entre capas y los cambios son
propagados al resto del código
• Consecuencias
• La dependencia entre capas es
externalizada y añadida
solamente cuando es desplegada
(al ultimo momento)
• Modelos reusables
Bridge (Glue Code)
Bridge (Glue Code)
Bridge (Glue Code)

Referencias
1. Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise. MDA
Distilled: Principles of Model-Driven Architecture. Addison
Wesley. 2004.

Métodos avanzados desarrollo software

Recomendados

Recomendados

Más contenido relacionado

Similar a Métodos avanzados desarrollo software

Similar a Métodos avanzados desarrollo software (20)

Más de Ricardo Tesoriero

Más de Ricardo Tesoriero (11)

Métodos avanzados desarrollo software

Notas del editor