2. 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. 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. 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. 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
Introducción al paradigma orientado a objetos
6. 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
Introducción al paradigma orientado a objetos
La orientación a objetos OO como solución
7. 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
Introducción al paradigma orientado a objetos
La orientación a objetos OO como solución
11. 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
Introducción al paradigma orientado a objetos
12. 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
Introducción al paradigma orientado a objetos
Objetos – Identidad – Oid (Object Identifier)
13. 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)
Introducción al paradigma orientado a objetos
14. 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
Introducción al paradigma orientado a objetos
15. 15
Introducción al paradigma orientado a objetos
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. 16
Comportamiento
Introducción al paradigma orientado a objetos
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. 17
Propiedades Fundamentales
Encapsulación: ocultación de la información
Introducción al paradigma orientado a objetos
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. 18
Abstracción: principio de
ignorar aquellos aspectos que
no son relevantes al propósito
de lo que se está realizando
Introducción al paradigma orientado a objetos
Propiedades Fundamentales
19. 19
Persistencia: característica
que se refiere a la
permanencia del objeto en
memoria
Introducción al paradigma orientado a objetos
Propiedades Fundamentales
Persistence saves the state and class of an object
across time or space
20. 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
Introducción al paradigma orientado a objetos
21. 21
Propiedades Fundamentales
Polimorfismo: propiedad por la
cual una misma función puede
encontrarse en diferentes clases
teniendo distintos parámetros y
realizando distintas acciones
Introducción al paradigma orientado a objetos
26. 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. 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. 28
El análisis y modelado
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. 29
El análisis y modelado
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. 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. 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. 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. 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. 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. 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)
UML (Unified Modeling Language)
38. Elementos
UML (Unified Modeling Language)
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. 39
Elementos Estructurales - Clase
UML (Unified Modeling Language)
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. 40
Elementos Estructurales - Objetos
UML (Unified Modeling Language)
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. 41
Elementos Estructurales
UML (Unified Modeling Language)
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. 42
Elementos Estructurales
UML (Unified Modeling Language)
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. 43
Elementos Estructurales
UML (Unified Modeling Language)
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. 44
Elementos Estructurales
UML (Unified Modeling Language)
Nota: Sirve para anotar comentarios en los modelos con
la finalidad de escribir, clarificar y hacer observaciones
50. 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
UML (Unified Modeling Language)