LENGUAJES DE

MODELADO
UNIDAD 1
INTRODUCCION AL MODELADO
 CONTENIDO

1. Introducción
2. Ingeniería del software
3. Proceso de desarrollo
1. Ciclo de vida del software
4. Metodologías de desarrollo
1. Ejemplos
5. Introducción a UML

2
DESARROLLO DE SOFTWARE

https://histinf.blogs.upv.es/2011/01/04/la-crisis-del-software/

3
 INGENIERÍA DEL SOFTWARE
❖ El desarrollo de un proyecto de ingeniería es complicado. La
finalidad de un proyecto es algo concreto, pero el punto de partida
suele ser algo intangible (conversaciones con el cliente, normas,
procedimientos de trabajo, necesidades genéricas, etc.).
❖ La ingeniería del software es la aplicación de un enfoque
sistemático, disciplinado y cuantificable en el proceso de desarrollo
de software.
• Se persigue la calidad (fiable, rápido, etc.) con el menor coste.
• Una metodología de desarrollo es un modo concreto de poner
en práctica ese enfoque sistemático (el cómo).
• Es muy importante en este proceso entender y gestionar qué
debería hacer el software (los requisitos del software).

4
 PROCESO DE DESARROLLO
❖ Es una secuencia de fases, actividades, métodos,
herramientas y roles que deben ser seguidas por
un equipo de trabajo, en el que quede definido lo
que cada trabajador que interviene debe realizar
como actividades y los productos que se deben
generar.

❖ No hay un proceso de desarrollo universal, hay

esquemas genéricos. Debe adaptarse de acuerdo
al tipo de producto, la experiencia de la empresa,
etc.

❖ La adopción por una empresa de un proceso de

desarrollo contrastado, le permite producir
software con plazos y costos predecibles y con
calidad constante, eliminando riesgos.

5
 CICLO DE VIDA DEL SOFTWARE
“Es un marco de referencia que contiene los procesos, las actividades y
las tareas involucradas en el desarrollo, la operación y el mantenimiento
de un producto software, abarcando la vida del sistema desde su
definición hasta su retirada” (ISO 12207).

❖ Tareas más comunes:

• Estudio de viabilidad. Identificación problemas, oportunidades, ..
• Captura de requisitos. Define las necesidades y expectativas
• Análisis. Qué hay que hacer. Toma de decisiones
• Diseño. Cómo hay que hacerlo. Diseño arquitectura del sistema
• Implementación. Desarrollo y documentación
• Validación y verificación. Incluye pruebas y el mantenimiento
• Evolución del sistema y mantenimiento.

6
 MODELO CICLO DE VIDA CLÁSICO (CASCADA)

Viabilidad

Definición y análisis de requisitos. Qué

Análisis
Organizar arquitectura software. Cómo
Diseño
Codificar. Depurar. Documentar
Implementación
De unidad. Integración
Pruebas
Mejoras.
Corrección errores
Mantenimiento
Recuperaciones de errores de alto coste
Evolución
Los requisitos NO deben cambiar en el proceso

7
 PROBLEMAS CICLO DE VIDA CLASICO
❖ En la vida real, un proyecto no trivial rara vez sigue una secuencia
lineal, esto crea una mala implementación “real” del modelo, y lo
lleva al fracaso. Conseguir una fase del ciclo de vida del software
perfecta antes de moverse a las siguientes fases es una mala idea.
❖ Difícilmente un cliente va a establecer al principio todos los
requisitos necesarios, este caso no está previsto en este modelo y
provoca un gran atraso (realimentaciones).
❖ Los resultados y/o mejoras no son visibles progresivamente, el
producto se ve cuando ya está finalizado, lo cual provoca una gran
inseguridad por parte del cliente que quiere ir viendo los avances en
el producto. Esto también implica que aparezcan requisitos que no
se habían tomado en cuenta inicialmente en este momento, lo cual
provocará que haya que volver de nuevo a la fase de requisitos.

8
VARIACIONES: CICLOS DE VIDA EN V / W

Ej.: metodología MADEJA: ciclo de vida y procesos

9
 CICLO DE VIDA ITERATIVO (EVOLUTIVO)
❖ Se basa en que para comprender,
diseñar, e implementar un sistema
complejo, deben emplearse
sucesivas etapas en las que en
cada una de ellas se realiza una
evolución respecto a la anterior
(evolución “natural”).
❖ Varios ciclos de vida en cascada
consecutivos (iteraciones).
❖ En cada iteración se obtiene
un ejecutable que puede ser
evaluado por el cliente.

10
CICLO DE VIDA INCREMENTAL

11
 CICLO DE VIDA ITERATIVO E INCREMENTAL
❖ Definido en respuesta a la debilidad del modelo en cascada.

12
 VENTAJAS/INCONVENIENTES
❖ Ventajas
• Se genera software operativo de forma rápida y en etapas
tempranas del ciclo de vida del software.
• Es un modelo más flexible, por lo que se reduce el coste en el
cambio de alcance y requisitos.
• Es más fácil gestionar, probar y depurar en una iteración más
pequeña.
• Es más fácil gestionar riesgos.
❖ Inconvenientes
• Se requiere una experiencia importante para definir las
iteraciones/incrementos y distribuir en ellos las tareas.
• Suele ser necesario realizar cambios en la arquitectura actual del
sistema al añadir requisitos en las iteraciones (refactorización).
• No hay una planificación completa, ni fecha de entrega, ni un
coste total. A veces el proyecto no tiene final a la vista.
13
OTROS CICLOS: ESPIRAL, PROTOTIPOS, RAD, ETC.

14
 METODOLOGÍAS DESARROLLO
❖ La metodología es un modo predecible, repetible y sistemático de
realizar, gestionar y administrar un proyecto a fin de mejorar la
productividad en el desarrollo y la calidad del producto software, y
llevarlo a cabo con altas posibilidades de éxito.
❖ Incluye un conjunto integrado de técnicas y métodos que permite
abordar de forma homogénea y abierta cada una de las actividades
del ciclo de vida de un proyecto de desarrollo. Es un proceso de
software detallado y completo.
❖ Una metodología de desarrollo no tiene que ser necesariamente
adecuada para usarla en todos los tipos de proyectos.
❖ Hay 2 grandes grupos: Las metodologías tradicionales haciendo
énfasis en la planificación y las metodologías ágiles haciendo
énfasis en la adaptabilidad del proceso.

15
 CLASIFICACIÓN DE METODOLOGÍAS
❖ Las metodologías tradicionales se caracterizan por:
• definir totalmente los requisitos al inicio del proyecto
• una planificación predictiva a largo plazo
• muchos entregables, documentación, complejidad y burocracia
• no permitir realizar cambios fácilmente

❖ Las metodologías ágiles (ligeras) se caracterizan por todo lo

contrario. Sus valores son:
1. Colaboración con el cliente antes que contratos/requisitos
2. Las personas/colaboración antes que procesos/herramientas
3. Software que funciona antes que documentación exhaustiva
4. Respuesta ante cambios antes que el seguimiento de un plan

www.agilemanifesto.org
16
 ALGUNAS METODOLOGÍAS

❖ Tradicionales:
✓ METRICA, MADEJA, etc.

❖ Tradicionales (con ciclos de vida iterativos):

✓ UP, RUP – Rational Unified Process – Metodología OO con
UML, …

❖ Agiles (en general tienen ciclos de vida iterativos):

✓ XP (eXtreme Programming), SCRUM, Kanban, Agile* Unified
Process, Design Thinking, Lean, etc.

17
 METODOLOGÍA UP/RUP
❖ Metodología orientada a objetos que utiliza UML (Unified Modeling
Language) para el modelado.
❖ Fases: inicio, elaboración, construcción y transición.
• El inicio identifica el alcance del proyecto, los riesgos y los
requisitos a alto nivel para que se pueda estimar el trabajo.
• La elaboración entrega una arquitectura que mitiga los riesgos
altos y cumple los requisitos no funcionales.
• La construcción reemplaza incrementalmente la arquitectura
con el resultado de las iteraciones (análisis, diseño,
implementación y pruebas) hasta completar todos los requisitos
funcionales.
• La transición entrega el sistema al entorno operativo de
producción (release).

18
METODOLOGÍA RUP

19
METODOLOGÍA SCRUM

20
SCRUM: PILA DE PRODUCTO

21
 MODELADO DE SISTEMAS
❖ El modelado de sistemas es el proceso de desarrollar el modelo
abstracto de un sistema, para abordar su complejidad a través de
diferentes vistas del sistema que se modela (“planos”).
❖ El modelo permite representar estas vistas del sistema utilizando
algún tipo de notación visual (diagrama), lo que ayuda al ingeniero
de software a "visualizar" el sistema a construir y a comunicarse.
❖ El Lenguaje de Modelado Unificado (UML)
es el lenguaje de modelado visual de
propósito general y orientado a objetos
más conocido y utilizado en la actualidad.
Es un estándar respaldado por el Object
Management Group (OMG).

22
 UML
❖ UML dispone de múltiples diagramas que permiten modelar
aspectos concretos con el adecuado nivel de detalle a lo largo de
todo el proceso de desarrollo e independientemente de la
metodología.
• Uso “ligero” en metodologías ágiles como apoyo en reuniones (a
mano) o a través de ingeniería inversa de código.
• Uso para crear un modelo UML completo (con herramientas).
✓ Un uso óptimo se consigue en procesos dirigidos por casos de uso,
centrados en la arquitectura, iterativos e incrementales (RUP)
❖ Un modelo UML de una aplicación puede tener muchos diagramas y
con muy diferente nivel de detalle:
• Modelo arquitectural: con información cualitativa de alto nivel.
• Modelos detallados: con información que permiten la validación
o la generación de código (Model Driven Architecture (MDA)).
23
TIPOS DE DIAGRAMAS UML (13)

24
EJEMPLO: DIAGRAMA UML DE CLASES

25
 BIBLIOGRAFÍA
❖ Roger S. PRESSMAN. Ingeniería del software: un enfoque práctico.
Adaptación europea. 5ª edición. McGraw-Hill.
❖ Grady BOOCH, James RUMBAUGH, Ivar JACOBSON. The Unified
Modeling Language. User Guide. Ed. Addison Wesley.

❖ Lecturas:
• Lecturas del tema disponibles en moodle
• Búsqueda web sobre los conceptos explicados en clase

26