Introducción a UML

Introducción a UML
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Marzo, 2021
Loja, Ecuador

3
1. Introducción al paradigma orientado a objetos
2. El Ingeniero de Software
3. El análisis y modelado
4. El modelo y diagramas
5. UML
Agenda

4
Introducción al paradigma orientado a objetos

Desarrollo de software tienen unos costes incontrolados

Origen de los fallos de los SI en el software

Las empresas gastan el 80% de su presupuesto en mantenimiento

El 95% de los nuevos sistemas, no satisfacen las necesidades de los nuevos
usuarios

Los sistemas generados son demasiado complejos e inflexibles para
adaptarse a las crecientes necesidades de las empresas
¿Por qué están fallando los sistemas de información (SI)?

5
¿Por qué están fallando los sistemas de información (SI)?

Diversos estudios han demostrado que un proyecto de desarrollo de software
típico:

rebasa en un 50% las fechas previstas

por cada seis que entran en fase de producción, dos son cancelados

Además un estudio realizado en 25 compañías norteamericanas:

el 55% de los proyectos software cuestan más de lo previsto

el 88% han de ser rediseñados

6
Entre los objetivos destacan:

Corrección: capacidad de satisfacer unas necesidades dadas, es decir, grado en el
que se satisfacen las expectativas del software

Robustez: capacidad por la que el software puede seguir en operación aunque se
hayan producido entradas no válidas

Reutilización: capacidad por la que un módulo puede utilizarse en múltiples
aplicaciones
La orientación a objetos OO como solución

7

Extensibilidad: mejora hecha al software existente para incrementar su
alcance y capacidad

Portabilidad: grado de facilidad con que puede transferirse un software de un
sistema o entorno de ordenador a otro

Facilidad de verificación: para determinar si los productos de una fase
determinada del ciclo de desarrollo software cumplen o no los requisitos
establecidos en la fase previa
La orientación a objetos OO como solución

8
Paradigma de programación estructurado vs. OO

9
La Clase

10
Clases y objetos

11
Objetos

Objeto = Identidad + Estado + Comportamiento

El estado está representado por los valores de los atributos

Un atributo toma un valor en un dominio concreto

12

Cada objeto posee un Oid y establece la identidad del objeto y tiene las
siguientes características:

Constituye un identificador único y global para cada objeto dentro del
sistema

Es determinado en el momento de la creación del objeto

Es independiente de la localización física del objeto, es decir, provee
completa independencia de localización
Objetos – Identidad – Oid (Object Identifier)

13
Objetos – Identidad – Oid (Object Identifier)

Cada objeto …...

Es independiente de las propiedades del objeto, lo cual implica
independencia de valor y de estructura

No cambia durante toda la vida del objeto. Además, un oid no se reutiliza
aunque el objeto deje de existir

No se tiene ningún control sobre los oids y su manipulación resulta
transparente

Sin embargo, es preciso contar con algún medio para hacer referencia a un
objeto utilizando referencias del dominio (valores de atributos)

14
Estado

El estado evoluciona con el tiempo

Algunos atributos pueden ser constantes

El comportamiento agrupa las competencias de un objeto y describe las
acciones y reacciones de ese objeto

Las operaciones de un objeto son consecuencia de un estímulo externo
representado como mensaje enviado desde otro objeto

15
El estado de un objeto abarca todas las propiedades del objeto, y los valores
actuales de cada una de esas propiedades
Las propiedades de los objetos suelen ser estáticas, mientras los valores que toman
estas propiedades cambian con el tiempo
El estado de un objeto representa el efecto acumulado de su comportamiento
Estado

16
Comportamiento

Los mensajes navegan por los
enlaces, a priori en ambas
direcciones

Estado y comportamiento están
relacionados

Ejemplo: no es posible aterrizar un
avión si no está volando. Está
volando como consecuencia de haber
despegado del suelo

17
Propiedades Fundamentales

Encapsulación: ocultación de la información
Ventajas

Modelos

Modularidad

Extensibilidad

Eliminación de redundancias
Inconvenientes

Dificultad de aplicación de una tecnología

Necesidad de mayor preparación del personal
Encapsulation hides the details of the
implementation of an object

18
Abstracción: principio de
ignorar aquellos aspectos que
no son relevantes al propósito
de lo que se está realizando

19
Persistencia: característica
que se refiere a la
permanencia del objeto en
memoria
Persistence saves the state and class of an object
across time or space

20
Persistencia

La persistencia de los objetos designa la capacidad de un objeto
trascender en el espacio/tiempo

Podremos después reconstruirlo, es decir, cogerlo de memoria
secundaria para utilizarlo en la ejecución (materialización del objeto)

Los lenguajes OO no proponen soporte adecuado para la persistencia, la
cual debería ser transparente, un objeto existe desde su creación hasta
que se destruya

21
Polimorfismo: propiedad por la
cual una misma función puede
encontrarse en diferentes clases
teniendo distintos parámetros y
realizando distintas acciones

25
El Ingeniero de Software
Ingeniería de Software

26
El Ingeniero de Software

Desarrollar, mantener y evaluar servicios y sistemas software que

Satisfagan todos los requisitos del usuario

Se comporten de forma fiable y eficiente

Sean asequibles de desarrollar y mantener

Cumplan normas de calidad

Valorar las necesidades del cliente y especificar los requisitos software para satisfacer estas
necesidades

Debe consiguir estos objetivos dentro de las limitaciones de coste, de tiempo, de la existencia
de sistemas ya desarrolladas y de las propias organizaciones

Solucionar problemas de integración en función de las estratégias, estándares y tecnologías
disponibles

Analizar problemas y diseñar, implementar, verificar y documentar soluciones

Identificar, evaluar y gestionar riesgos potenciales

27
El análisis y modelado
Análisis de requisitos de software: El proceso de reunión de requisitos se
intensifica y se centra especialmente en el software. Dentro del proceso de
análisis es fundamental que a través de una colección de requisitos
funcionales y no funcionales, el desarrollador o desarrolladores del
software comprendan completamente la naturaleza de los programas que deben
construirse para desarrollar la aplicación, la función requerida,
comportamiento, rendimiento e interconexión

28

El uso de modelos ayuda al
ingeniero de software a
"visualizar" el sistema a
construir

Los modelos de un nivel de
abstracción mayor pueden
utilizarse para la
comunicación con el cliente

Las herramientas de modelado
y las de Ingeniería de
Software Automatizada,
pueden ayudar a verificar la
corrección del modelo

29

El objetivo es describir en detalle todas las facetas de un sistema software

Utilización

Comportamiento de procesos

Estructura de software y hardware

Componentes

El documento debe poder ser interpretado por el equipo de desarrollo del
sistema

Con el fin de universalidad y facilitar la compresión, se hace uso del modelado

30
Modelos y diagramas

Modelar consiste en diseñar aplicaciones software antes de su
implementación. Es una parte esencial en proyectos de tamaño medio o grande

Un modelo es una abstracción de un elemento del sistema a desarrollar, desde
un punto de vista determinado y, por lo tanto, con un nivel de detalle específico

Un diagrama consiste en representación gráfica de una colección de modelos
para representar una parte específica del sistema. Se suele representar con un
grafo

32
Modelos y diagramas

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que
permitan expresar el producto desde cada una de las perspectivas de interés

Cada modelo es completo desde un punto de vista del usuario al que va dirigido

34

Con el modelado del sistema podemos definir todos los requisitos de forma
totalmente a su implementación

Esto permite tener una visión global del sistema antes de iniciar su desarrollo,
lo que implica:

Tener unos requisitos bien definidos

Reducir problemas en el proceso de implementación

Tener una visión global del sistema en una primera fase de desarrollo

Para poder modelar un sistema y conducir el proceso de desarrollo, es
necesario el uso de una solución software
Modelos y diagramas

35
Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que
permitan expresar el producto desde cada una de las perspectivas de interés
El código fuente del sistema es el modelo más detallado del sistema (y además
es ejecutable). Sin embargo, se requieren otros modelos ...
Cada modelo es completo desde su punto de vista del sistema, sin embargo,
existen relaciones de trazabilidad entre los diferentes modelos
Modelos y diagramas

36

Es un lenguaje de propósito general que ayuda a especificar, visualizar y documentar
modelos de sistemas, incluido su estructura y diseño, de tal forma que se unifiquen todos
sus requisitos – Definición oficial de UML

El objetivo principal es estandarizar el modelado de sistemas de software

Proporciona vocabulario y reglas para combinar y construir representaciones, modelos
conceptuales y fisicos del sistemas

Permite representar varios modelos, combinando notaciones especificas de cada uno

El 80% de los problemas pueden modelarse usando alrededor del 20% de UML (Grady
Booch)
UML (Unified Modeling Language)

37
Notación para especificación, construcción y documentación de artefactos de
sistemas de software, modelos de negocio y otros sistemas
 Propone técnicas para:
„

Especificaciones

Diseño

Implementación
Proporcionar a los desarrolladores un lenguaje que permita intercambiar modelos de
conocimiento
Permitir extensibilidad y especialización para poder trabajar en diferentes entornos
Unificar las distintas notaciones existentes en Orientación a Objetos en un entorno
estándar, estable y configurable
Incorporar las ventajas principales de los métodos más conocidos (Booch, OMT y
OOSE)

Elementos
Estructurales

Partes estáticas del modelo

Representan elementos conceptuales, físicos o materiales

Clase, objtetos, interfaces, casos de uso, actor, etc
Comportamiento

Describen el funcionamiento de un sistema

Interacciones, máquinas de estado
Agrupación

Permiten agrupar otros elementos del modelo

Componentes, paquetes, nodos
Anotación

Sirven para realizar anotaciones extas

Notas

39
Elementos Estructurales - Clase
Una clase es una definición de un modelo abstracto de datos, que incluyen todos
los atributos y métodos del elemento a modelar
Engloba el estado y el comportamiento de un elementos del sistema a modelar
Punto de vista de la implmentación

40
Elementos Estructurales - Objetos
Instancia de una clase
En UML se representa por un rectángulo
con el nombre del objeto subrayado
El estado del objeto se representa por
valores del atributo

41
Elementos Estructurales
Actor: conjunto de roles que desempeññan los
usuarios del sistema, un actor no tiene por qué ser un
ser humano, ya que puede representar a otro sistema
en un proceso de interacción
Caso de Uso: Es una descripción de un conjunto de
secuencias de acciones que el sistema ejecuta y
produce resultado observable para un actor.
Representa una funcionalidad del sistema

42
Nodo: es un elemento físico que representa un recurso
del sistema
Componente: elemento estructural de software que
representa una parte autónoma del mismo. Empaqueta
un conjunto de funcionalidad o datos utilizados en la
implementación (tablas, ficheros, librerías, etc.)

43
Iteración: conjunto de mensajes entre elementos de los
diferentes diagramas. El propósito del mensaje cambia
según el contextoen el que muestre
Estado: situación en un espacio y tiempo determinado
que tiene un elemento en el sistema. Sirve para
especificar el comportamiento de dicho elemento

44
Nota: Sirve para anotar comentarios en los modelos con
la finalidad de escribir, clarificar y hacer observaciones

45
UML - Diagramas

46
UML - Diagramas

47
UML – 4 + 1 Vistas de Krutchen

48

49
Iconix

50
Retos
Por qué es necesario UML
La concepción de UML
Explicación de cada uno de los diagramas a través de su uso y un
ejemplo
Conocer la utilidad del diagrama y por que tanto diagrama

51
Cŕeditos
• Transparencias basadas por:
• Christopher Exposito Izquierdo & AiRam Exposito Marquez & otros
• Maria-Isabel, Sanchez Segura & Arturo, Mora-Soto

Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
52
Gracias

Introducción a UML

Más contenido relacionado

La actualidad más candente (20)

Similar a Introducción a UML (20)

Más de Rene Guaman-Quinche (20)

Último (6)

Introducción a UML