Análisis y Diseño de Sistemas

Diagrama de Clases y Objetos

Logro de la Sesión
• Al finalizar la sesión, el estudiante diseña diagramas de clases y de secuencia de manera
gráfica, respetando su nomenclatura, sus relaciones, dependencia y clasificación a nivel
de clase y con la capacidad de aplicarlas en casos particulares, tales como: Clase
abstracta, parametrizada, asociación, activa, utilidad, interfaz, hoja y raíz, con rigurosidad
y responsabilidad.
Contenido Temático
• Diagrama de Clases y Objetos.
• Clase, Diagrama de Clase, Diagrama de objetos.
• Atributos: públicos, privados, protegidos.
• Relación entre clases:
• Generalizada. Dependencia
• Clasificación de una relación de asociación.
• Asociaciones entre clases:
• Agregación. Composición. Clasificación: Asociación.
• AND, Asociación XOR.
1. WorkFlow
• El flujo de trabajo (WorkFlow en inglés) es el estudio de los aspectos operacionales de una
actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden
correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo
se le hace seguimiento al cumplimiento de las tareas.

• Generalmente los problemas de flujo de trabajo se modelan con redes de Petri.

• WorkFlow o flujo de trabajo consiste en el estudio las operaciones que se realizan para
llevar a cabo una actividad de trabajo.

• Con la utilización de los WorkFlow y su implementación con la tecnología, lo que se

consigue es la automatización de procesos de negocio, en los cuales los documentos, la
información y las tareas pasan de una persona o departamento a otro, siguiendo una cierta
jerarquía y de acuerdo con un protocolo preestablecido que debe cumplirse para su
correcta realización.
1. WorkFlow

• Los flujos de trabajo también son útiles para ayudar a los empleados a entender sus
funciones y el orden en el cual se completa el trabajo, y para crear más unidad dentro
de departamentos diferentes.
1. WorkFlow - Beneficios
• Las comunicaciones entre personas o departamentos dentro de la empresa van a ser más
sencillas, más ágiles y mucho más seguras.

• Las tareas estarán mucho más optimizadas.

• La división del trabajo será más clara y más comprensible por parte de todas las personas
o departamentos de la empresa implicados, de forma que las tareas sean mucho más
efectivas.

• Permite ahorrar tiempo y mejorar la productividad del negocio eliminando tareas

innecesarias o procesos administrativos que generan un coste para la empresa en tiempo y
dinero.

• También permite integrar todos los procesos empresariales. Esta es una característica
fundamental de los sistemas WorkFlow ya que se integra perfectamente con los sistemas de
información actuales, como bases de datos, gestión documental, mensajería, ERP.
1. WorkFlow - Ejemplo
• El primero de ellos es el ejemplo de un WorkFlow donde un usuario rellena un formulario
para solicitar un e-book de información:
1. WorkFlow - Ejemplo
• Otro ejemplo de WorkFlow es la monitorización de los usuario en la web y según las
iteraciones que tenga en ella ofrecerle campañas personalizadas:
1. WorkFlow - Representación
• La representación de un WorkFlow es la descripción de un conjunto de procesos y sus
reglas de cambio para que este pueda ser automatizado.

• Para poder realizar esta representación es necesario definir un lenguaje formal con el que
los actores puedan entenderse.

• En el caso de un WorkFlow gráfico el lenguaje estará determinado según las reglas que
permita unir los círculos con los cuadros utilizando los conectores correspondientes.
1. WorkFlow - Nomenclatura
1. WorkFlow – Tipos de Diagramas
• Diagrama de flujo ANSI:
• Con el uso de símbolos del Instituto Nacional Estadounidense de Estándares
(ANSI, por sus siglas en inglés), el estilo ANSI fue el primer estándar para los
flujos de trabajo y proporciona un lenguaje común para describir los
diferentes pasos implicados.
1. WorkFlow – Tipos de Diagramas
• Diagrama de actividades UML:
• Con el uso del Lenguaje Unificado de Modelado (UML, por sus siglas en
inglés), el diagrama de actividades UML se emplea para representar
gráficamente el orden de los pasos en un proceso y el flujo de control.

Venta de Producto
1. WorkFlow – Tipos de Diagramas
• Diagrama BPMN:
• Con el significado de Notación de Modelado de Procesos de Negocios, el
diagrama BPMN (por sus siglas en inglés) usa una técnica de diagrama de
flujo similar a la del diagrama UML.

• Sirve como lenguaje común tanto para usuarios técnicos como para
usuarios de negocios.

• Se enfoca en el proceso y la información de negocios (por ejemplo, procesos

internos), en lugar de en los resultados.
1. WorkFlow – Tipos de Diagramas
• Diagrama BPMN
1. WorkFlow – Tipos de Diagramas
• Diagrama de carriles:
• Un diagrama de carriles separa a cada unidad dentro de la organización,
resaltando su interacción y brindando una vista de nivel superior de las
posibles ineficiencias.
1. WorkFlow – Tipos de Diagramas
• Diagrama SIPOC:
• Por sus siglas en inglés, este acrónimo significa Proveedor-Entrada-Proceso-
Salida-Cliente, lo cual muestra claramente quién crea y recibe los datos y
describe el proceso de alto nivel implicado.
1. WorkFlow – Tipos de Diagramas
• Diagrama SIPOC:
1. WorkFlow – Documentación
• Si esperas un listado de los procesos que necesitan un WorkFlow con la
documentación, lo siento, pero no existe.

• Todo depende de los procesos que existan en tu empresa y la forma en la que

ésta desee automatizar el flujo de vida de los documentos.

• Para saber si nuestra organización necesita sistemas de WorkFlow para

automatizar nuestra gestión documental deberíamos preguntarnos cosas como:

• ¿Nuestro proceso de gestión documental es eficiente?

• ¿Sabemos en todo momento quién es el responsable de cada una de las

tareas en los procesos de creación y gestión de documentos?

• ¿Cómo sabemos sin los cambios realizados provocan mejoras?

1. WorkFlow – Documentación
• Una documentación resume los pasos necesarios para completar una tarea o
proceso.

• Es una documentación interna y continua mientras se lleva a cabo; en la

documentación es más importante el "cómo" de la implementación que el
"cuánto" del impacto.

• Un negocio es esencialmente un grupo de procesos interrelacionados, y si estos

procesos no están documentados por escrito, puede haber inconvenientes.

• Las empresas tienen procesos repetibles que son clave para que sus operaciones
sean exitosas, por lo que la documentación de procesos sirve como una guía
fundamental de referencia para los empleados y directores.

• La documentación también te permite saber qué está haciendo la gente y

obtener información valiosa sobre los trabajos internos de la empresa
2. Clases - Concepto
2. Clases - Concepto
2. Clases - Abstracción
2. Clases - Características
2. Clases - Multiplicidad
2. Clases
2. Clases
2. Clases – Visibilidad de Atributos
2. Clases – Niveles de Visibilidad
2. Clases – Tipo de Característica
2. Clases – Atributos - Multiplicidad
2. Clases
2. Clases – Modificadores de Atributos
2. Clases - Colección
2. Clases: Operación Vs Método
2. Clases – Sintaxis de Operación
2. Clases - Sintaxis de Parámetro de Operación
2. Clases
2. Clases
2. Clases - Relaciones
2. Clases - Dependencia
2. Clases - Estereotipos de Dependencia
2. Clases - Estereotipos de Dependencia
• El siguiente ejemplo nos muestra un conjunto de cuatro clases junto con
sus asociaciones y sus dependencias, correspondientes a una parte de
un sistema que gestiona la asignación de profesores a los cursos en una
universidad.

• En el ejemplo hay una dependencia normal de la clase Planificación del

Curso respecto a la clase Curso, pues Curso se utiliza como parámetro en
las operaciones Añadir y Eliminar de Planificación del Curso.

• Si proporcionamos la lista de parámetros en las operaciones, tal como se

puede observar en el ejemplo, entonces no es necesario mostrar la
dependencia, pues la utilización de la clase Curso ya figura de forma
explícita en la clase Planificación del Curso.

• Sin embargo, a veces queremos que esta dependencia se dibuje,

especialmente si hemos omitido la lista de parámetros en las
operaciones.
2. Clases - Estereotipos de Dependencia

En el ejemplo aparecen otras dos dependencias marcadas con un estereotipo.

Una de ellas es la dependencia «derive» entre los atributos edad y fecha-de-cumpleaños, la cual no se
marca de forma explícita, sino como: /edad.
La otra es la dependencia «friend» de la clase Iterador respecto a la clase Planificación del Curso. Esta
dependencia muestra el uso de un iterador, especificado en la clase Iterador, sobre la programación del
curso, especificada en la clase Planificación del Curso. Sin embargo, esta última clase no sabe nada acerca
de la primera.
2. Clases - Generalización
2. Clases - Generalización

• En este ejemplo la clase Vehículo muestra las cosas comunes entre

coches y barcos, incluyendo la relación de asociación a la clase Persona.
Se trata de una clase abstracta que no tiene objetos, mientras que las
clases Coche y Barco son concretas.
• Estas subclases heredan el atributo color y la operación Conducir de la
superclase Vehículo.
• Dicha operación está redefinida en las clases Coche y Barco, ya que no
está implementada en la clase Vehículo al aparecer junto a la operación
la palabra {abstracta} y además su implementación es diferente
dependiendo del tipo de objeto: coche o barco.
2. Clases - Generalización
2. Clases – Jerarquías de Generalización
2. Clases – Jerarquía de Generalización
2. Clases - Herencia
2. Clases – Herencia Múltiple
2. Clases – Grupos de Generalización
2. Clases – Grupos de Generalización: Propiedades
2. Clases – Grupos de Generalización: Propiedades
2. Clases - Asociación
2. Clases – Multiplicidad de una Asociación
2. Clases - Multiplicidad de una Asociación
2. Clases - Multiplicidad de una Asociación
Ejemplo:
2. Clases - Multiplicidad de una Asociación
Ejemplo:
2. Clases – Asociación: Características Avanzadas
2. Clases – Asociación: Navegación
2. Clases – Asociación: Navegación
2. Clases – Asociación: Visibilidad
2. Clases – Asociación: Visibilidad
2. Clases – Asociación: Búsqueda
2. Clases - Asociación: Búsqueda
2. Clases – Asociación: Nivel de Significado
2. Clases - Composición
2. Clases - Composición
2. Clases - Composición
2. Clases – Asociación: Atributos
2. Clases – Asociación: Atributos
2. Clases – Asociación: Modificadores
2. Clases Avanzadas: Clasificadores
• Un clasificador es un mecanismo que describe las características de estructura y
de comportamiento.

• UML proporciona un gran número de tipos de clasificadores, aparte de las

clases, que nos pueden ayudar a modelar nuestro proyecto del mundo real.

• Interfaz: Un conjunto de operaciones que se utilizan para especificar un

servicio de una clase o de un componente.

• Tipo de datos (datatype): Un tipo cuyos valores no tienen identidad,

incluyendo tipos primitivos (tales como enteros y cadenas de caracteres),
así como tipos enumerados (tales como booleanos).

• Señal (signal): La especificación de un estímulo asíncrono comunicado entre

instancias.

• Componente: Una parte física de un sistema que proporciona la ejecución

de un conjunto de interfaces.
2. Clases Avanzadas: Clasificadores

• Nodo: Un elemento físico en tiempo de ejecución, que representa un

recurso de ordenador, generalmente con memoria y capacidad de
procesamiento.

• Caso de uso: Una descripción de un conjunto de acciones, incluyendo

variantes, que un sistema lleva a cabo tras recibir un estímulo por
parte de un actor en particular.

• Subsistema: Un grupo de elementos de los cuales algunos constituyen

una especificación del comportamiento ofrecido por los otros
elementos contenidos en el mismo.
2. Clases Avanzadas: Clasificadores
3. Interfaces
• Una interfaz describe sólo operaciones abstractas, que especifican un
comportamiento que un elemento (paquete, componente o clase) puede elegir
soportar implementando la interfaz.

• A diferencia de las clases, las interfaces no especifican ninguna estructura (por ello
no incluyen atributos) ni ninguna implementación (por ello no incluyen métodos,
los cuales proporcionan la implementación de una operación).

• Estas operaciones abstractas pueden ser adornadas con propiedades de visibilidad

y con restricciones.

• Al igual que las clases, las interfaces pueden participar en relaciones de asociación,
dependencia y generalización.
3. Interfaces
• Las interfaces se representan gráficamente por medio de un círculo pequeño con
un nombre situado debajo de él. Se conectan a sus elementos mediante una línea
continua, que representa una relación de asociación con multiplicidad 1-1.

• Una clase que usa la interfaz implementada en una clase específica se conecta al
círculo de dicha interfaz mediante una relación de dependencia (línea
discontinua).

• La clase dependiente sólo depende de las operaciones de la interfaz, no depende

de ninguna de las operaciones de la clase que la implementa (en cuyo caso, la
relación de dependencia debería apuntar al símbolo de dicha clase).

• La clase dependiente podría llamar a las operaciones declaradas en la interfaz, las

cuales no se muestran directamente en el diagrama.

• Para verlas es necesario que la interfaz sea especificada como una clase con el
estereotipo «interfaz» dentro del rectángulo y por encima de su nombre.
3. Interfaces

La clase A implementa las interfaces Ejecutable y Almacenable y la clase C la interfaz Ejecutable.

La clase B usa las operaciones de las interfaces Ejecutable y Almacenable implementadas en A y las de
Ejecutable implementada en C.

Las interfaces son especificadas como clases con el estereotipo «interfaz» y contienen las operaciones
abstractas que las clases que las implementan tienen que implementar
3. Paquetes

• Un paquete es un mecanismo para agrupar clases u otros elementos de otro

tipo de diagramas en modelos más grandes, donde dichos elementos pueden
ser linkeados.

• Muchas metodologías de OO usan el término subsistema para describir un

paquete.

• Los paquetes o subsistemas se representan gráficamente por medio de un

rectángulo grande junto con otro más pequeño situado en la esquina superior
izquierda del rectángulo mayor.

• Si los contenidos de los paquetes no se muestran, entonces el nombre del

paquete debe ir dentro del rectángulo grande; en caso contrario dentro del
rectángulo pequeño.

• Las relaciones permitidas entre paquetes son dependencia y generalización.

3. Paquetes
4. Bibliografía
• Pressman, R. S. (2014) Ingeniería de Software: Un enfoque práctico, 7ma. edición. Editorial
McGraw- Hill.
• Kimmel, P. (2006) Manual de UML: Guía de Aprendizaje. Editorial McGraw- Hill.
• Schmuller, J. Aprendiendo UML en 24 horas. Editorial Prentice Hall.
GRACIAS