DIAPOSITIVA # 1: DIAGRAMA DE CLASES.

2 TIPOS DE DIAGRAMAS:
–Diagramas de estructura
• Proporcionar una forma de representar los datos y las relaciones estáticas que se encuentran en un sistema de información
• Diagrama de clase
–Diagramas de comportamiento
DIAGRAMAS DE ESTRUCTURA
• Diagrama de clase
- Describir la estructura del sistema en términos de clases y objetos.
- Propósito principal durante el flujo de trabajo de análisis: crear un vocabulario que sea utilizado tanto por el analista como por los usuarios
¿QUÉ ES UNA CLASE?
• Una plantilla general que usamos para crear instancias u objetos específicos en el dominio de la aplicación.
• Representa un tipo de persona, lugar o cosa sobre la cual el sistema necesitará capturar y almacenar información
• Abstracciones que especifican los atributos y comportamientos de un conjunto de objetos.
¿QUÉ ES UN OBJETO?
• Entidades que encapsulan estado y comportamiento.
• Cada objeto tiene una identidad: - Puede ser referido individualmente.
- Es distinguible de otros objetos.
TIPOS DE CLASES
• Unos encontrados durante el análisis:
- personas, lugares, eventos y cosas sobre las cuales el sistema capturará información
- Los que se encuentran en el dominio de la aplicación
• Unos encontrados durante el diseño:
- objetos específicos como ventanas y formularios que se utilizan para construir el sistema
2 TIPOS DE CLASES DURANTE EL ANÁLISIS
• Concreto: - Clase de dominio de aplicación
- Ejemplo: clase de cliente y clase de empleado
• Abstracto - Abstracciones útiles.
- Ejemplo: clase de persona
ATRIBUTOS EN UNA CLASE
• Propiedades de la clase sobre las que queremos capturar información.
• Representa una información que es relevante para la descripción de la clase dentro del dominio de la aplicación
ATRIBUTOS EN UNA CLASE
• Solo agrega atributos que son primitivos o tipos atómicos
• Atributo derivado - Atributos calculados o derivados de otros atributos.
- denotado colocando una barra (/) antes del nombre
OPERACIONES EN UNA CLASE
• Representa las acciones o funciones que una clase puede realizar
• Describe las acciones a las que las instancias de la clase serán capaces de responder
• Se puede clasificar como un constructor, consulta o operación de actualización
REPRESENTACIÓN UML DE CLASE

EJEMPLO DE UN DIAGRAMA DE CLASE: SISTEMA DE ALQUILER DE VIDEO

VISIBILIDAD DE ATRIBUTOS Y OPERACIONES

• Se relaciona con el nivel de información que debe ocultarse.

RELACIONES ENTRE CLASES

• Representa una conexión entre varias clases o una clase y sí mismo
• 3 categorías básicas:
- relaciones de asociación
- relaciones de generalización
- relaciones de agregación
RELACIÓN DE ASOCIACIÓN
• Una conexión semántica bidireccional entre clases.
• Tipo: - nombre de la relación
- Papel que juegan las clases en la relación.
RELACIÓN DE ASOCIACIÓN
Nombre del tipo de relación mostrado por:
- trazar linea entre clases
- Etiquetado con el nombre de la relación.
- indicando con un pequeño triángulo sólido al lado del nombre de la relación la dirección de la asociación

RELACIÓN DE ASOCIACIÓN
• Tipo de rol mostrado por:
- trazar linea entre clases
- indicando con un signo más antes del nombre del rol

RELACIÓN DE GENERALIZACIÓN
• Permite al analista crear clases que heredan atributos y operaciones de otras clases
• Representado por A-KIND-OF (una- especie- de) relación

RELACIÓN DE AGREGACIÓN
• Forma de asociación especializada en la que un todo está relacionado con su (s) parte (s)
• Representado por A-PART-OF (una-parte-de) relación
RELACIÓN DE AGREGACIÓN
• Se indica colocando un diamante más cercano a la clase que representa la agregación

MULTIPLICIDAD
• Documenta cuántas instancias de una clase se pueden asociar con una instancia de otra clase

MULTIPLICIDAD: Indica el número mínimo, número máximo de instancias

DIAGRAMA DE CLASE
2 enfoques para derivar diagramas de clase: - De los casos de uso y sus escenarios.
- De tarjetas CRC
DERIVANDO EL DIAGRAMA DE CLASE DE CASOS DE USO Y ESCENARIOS
• Analizar el texto en las descripciones de casos de uso y escenarios.
PAUTAS PARA ANALIZAR CASOS DE USO
• Un nombre común o impropio implica una clase de objetos
• Un nombre propio implica una instancia de una clase.
• Un nombre colectivo implica una clase de objetos formada por grupos de instancias de otra clase.
PAUTAS PARA ANALIZAR CASOS DE USO (2)
• Un adjetivo implica un atributo de un objeto.
• Hacer un verbo implica una operación.
• Un verbo implica una relación entre un objeto y su clase.
• Tener un verbo implica una agregación o relación de asociación
PAUTAS PARA ANALIZAR CASOS DE USO (3)
• Un verbo transitivo implica una operación.
• Un verbo intransitivo implica una excepción.
• Un predicado o frase verbal descriptiva implica una operación
• Un adverbio implica un atributo de una relación o una operación
DIAGRAMA DE CLASE
• Asegúrese de que las clases sean necesarias y suficientes para resolver el problema subyacente
- no faltan atributos o métodos en cada clase
- no hay atributos o métodos adicionales o no utilizados en cada clase
- no hay clases extra o extra
DESCARTANDO CLASES INNECESARIAS E INCORRECTAS
• Clases redundantes
• Clases irrelevantes
• Clases vagas
• Atributos
• Operaciones
• roles
• Construcciones de implementación
TIPOS DE CLASES
• Unos encontrados durante el análisis:
- personas, lugares, eventos y cosas sobre las cuales el sistema capturará información
- Los que se encuentran en el dominio de la aplicación
• Unos encontrados durante el diseño:
- objetos específicos como ventanas y formularios que se utilizan para construir el sistema

DIAPOSITIVA # 2: SOFTWARE DESIGN.

CLASES
Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.
Gráficamente, una clase se representa como un rectángulo, que generalmente incluye su nombre, atributos y operaciones en
compartimientos designados separados.
NOMBRES DE CLASE
El nombre de la clase es la única etiqueta requerida en la representación gráfica de una clase. Siempre aparece en el compartimento
más alto.
ATRIBUTOS DE CLASE
Un atributo es una propiedad con nombre de una clase que describe el objeto que se está modelando. En el diagrama de clase, los atributos aparecen en el segundo compartimento
justo debajo del compartimiento de nombres.
ATRIBUTOS DE CLASE (CONTINUACIÓN)
Los atributos se enumeran generalmente en la forma: attributeName: Type
Un atributo derivado es uno que se puede calcular a partir de otros atributos, pero en realidad no existe. Por ejemplo, la edad de una persona se puede
calcular a partir de su fecha de nacimiento. Un atributo derivado se designa por un ‘/’ anterior como en: / edad: fecha
Los atributos pueden ser:
+ público
# protegido
- privado
/ derivado
Operaciones de clase:
Las operaciones describen el comportamiento de la clase y aparecen en el tercer compartimento.

Puede especificar una operación indicando su firma: listando el nombre, el tipo y el valor predeterminado de todos los parámetros y, en el caso de las funciones, un tipo de
retorno.
CLASES DE REPRESENTACION
Al dibujar una clase, no es necesario mostrar los atributos y la operación en cada diagrama.

RESPONSABILIDADES DE CLASE
Una clase también puede incluir sus responsabilidades en un diagrama de clase.
Una responsabilidad es un contrato u obligación de una clase para realizar un servicio en particular.

RELACIONES
En UML, las interconexiones de objetos (lógicas o físicas), se modelan como relaciones.
Hay tres tipos de relaciones en UML:
• dependencias
• generalizaciones
• asociaciones
RELACIONES DE DEPENDENCIA
Una dependencia indica una relación semántica entre dos o más elementos. La dependencia de CourseSchedule a Course existe porque Course se usa en las operaciones de
agregar y eliminar de CourseSchedule.

RELACIONES DE GENERALIZACIÓN
Una generalización conecta una subclase a su superclase. Denota una herencia de atributos y comportamiento de la superclase a la subclase e indica una
especialización en la subclase de la superclase más general.

UML permite que una clase herede de múltiples superclases, aunque algunos lenguajes de programación (por ejemplo, Java) no permiten herencia múltiple.

RELACIONES DE ASOCIACIÓN
Si dos clases en un modelo necesitan comunicarse entre sí, debe haber un vínculo entre ellas. Una asociación denota ese enlace.

Podemos indicar la multiplicidad de una asociación agregando adornos de multiplicidad a la línea que denota la asociación.
El ejemplo indica que un estudiante tiene uno o más instructores:

El ejemplo indica que cada Instructor tiene uno o más Estudiantes:

También podemos indicar el comportamiento de un objeto en una asociación (es decir, la función de un objeto) utilizando nombres de rol.

También podemos nombrar la asociación.

Podemos especificar asociaciones duales.

Podemos restringir la relación de asociación definiendo la navegabilidad de la asociación. Aquí, un objeto Enrutador solicita servicios de un objeto DNS enviando mensajes
(invocando las operaciones de) el servidor. La dirección de la asociación indica que el servidor no tiene conocimiento del enrutador.

Las asociaciones también pueden ser objetos en sí, llamadas clases de enlace o clases de asociación.

Una clase puede tener una auto asociación.

Podemos modelar objetos que contienen otros objetos por medio de asociaciones especiales llamadas agregaciones y composiciones.
Una agregación especifica una relación de parte completa entre un agregado (un todo) y una parte constituyente, donde la parte puede existir independientemente del agregado.
Las agregaciones se indican mediante un adorno de diamante hueco en la asociación.

Una composición indica una propiedad sólida y una vida en coincidencia de partes por parte del conjunto (es decir, viven y mueren como un todo). Las composiciones están
denotadas por un adorno de diamante lleno en la asociación.
INTERFACES
Una interfaz es un conjunto de operaciones con nombre que especifica el comportamiento de los objetos sin mostrar su estructura interna. Puede
representarse en el modelo mediante un rectángulo de uno o dos compartimientos, con el estereotipo <<interfaz>> sobre el nombre de la interfaz.
SERVICIOS DE INTERFAZ
Las interfaces no se instancian. No tienen atributos ni estado. Más bien, especifican los servicios ofrecidos por una clase relacionada.

RELACIÓN DE REALIZACIÓN DE LA INTERFAZ

Una relación de realización conecta una clase con una interfaz que proporciona su especificación de comportamiento. Se representa mediante una línea discontinua con un
triángulo hueco hacia el especificador.

INTERFACES
Una interfaz de clase también puede representarse mediante un círculo conectado a una clase mediante una línea continua.

CLASE PARAMETRIZADA
Una clase o plantilla parametrizada define una familia de elementos potenciales.
Para usarlo, el parámetro debe estar enlazado.
Una plantilla se representa mediante un pequeño rectángulo discontinuo superpuesto en la esquina superior derecha del rectángulo de la clase. El
rectángulo discontinuo contiene una lista de parámetros formales para la clase.

El enlace se realiza con el <<bind>> estereotipo y un parámetro para proporcionar a la plantilla. Estos son adornos de la flecha discontinua que denota la
relación de realización.
Aquí creamos una lista de nombres vinculados para la Lista del Decano.

ENUMERACIÓN
Una enumeración es un tipo de datos definido por el usuario que consta de un nombre y una lista ordenada de literales de enumeración.

EXCEPCIONES
Las excepciones se pueden modelar como cualquier otra clase.
Observe el <<excepción>> estereotipo en el compartimento de nombres.
PAQUETES
Un paquete es un elemento similar a un contenedor para organizar otros elementos en grupos.
Un paquete puede contener clases y otros paquetes y diagramas.
Los paquetes se pueden utilizar para proporcionar acceso controlado entre clases en paquetes diferentes.

Las clases en el paquete FrontEnd y las clases en el paquete BackEnd no pueden acceder entre sí en este diagrama.

Las clases en el paquete BackEnd ahora tienen acceso a las clases en el paquete FrontEnd.

Podemos modelar generalizaciones y dependencias entre paquetes.

DIAGRAMA DE COMPONENTES
Los diagramas de componentes son uno de los dos tipos de diagramas que se encuentran en el modelado de los aspectos físicos de un sistema orientado a objetos. Muestran la
organización y las dependencias entre un conjunto de componentes.
Utilice diagramas de componentes para modelar la vista de implementación estática de un sistema. Esto implica modelar las cosas físicas que residen en un nodo, como
ejecutables, bibliotecas, tablas, archivos y documentos.
- La Guía del usuario de UML, Booch et. al., 1999
Aquí hay un ejemplo de un modelo de componente de una versión ejecutable. [Booch, 99]

DIAGRAMA DE DESPLIEGUE
Los diagramas de implementación son uno de los dos tipos de diagramas que se encuentran al modelar los aspectos físicos de un sistema orientado a objetos. Muestran la
configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que viven en ellos.
Utilice diagramas de implementación para modelar la vista de implementación estática de un sistema. Esto implica modelar la topología del hardware en el que se ejecuta el
sistema. - La Guía del usuario de UML, [Booch, 99]

Un componente es una unidad física de implementación con interfaces bien definidas que se pretende utilizar como parte reemplazable de un sistema. Los componentes bien
diseñados no dependen directamente de otros componentes, sino de las interfaces que admiten los componentes. - El Manual de Referencia UML, [Rumbaugh, 99]
Diagrama de despliegue de un sistema cliente-servidor.

DISEÑO DE SOFTWARE : MODELADO DINÁMICO UTILIZANDO EL LENGUAJE DE MODELADO UNIFICADO (UML)

CASO DE USO
"Un caso de uso especifica el comportamiento de un sistema o una parte de un sistema, y es una descripción de un conjunto de secuencias de acciones, incluidas las variantes,
que realiza un sistema para proporcionar un resultado observable de valor para un actor". - La Guía del usuario de UML, [Booch, 99]
“Un actor es una idealización de una persona, proceso o cosa externa que interactúa con un sistema, subsistema o clase. Un actor caracteriza las interacciones que los usuarios
externos pueden tener con el sistema ". - El Manual de Referencia UML, [Rumbaugh, 99]

Un caso de uso se representa como una elipse en un diagrama de casos de uso. Un caso de uso siempre está etiquetado con su nombre.

Un actor se representa como una figura de palo en un diagrama de caso de uso. Cada actor participa en uno o más casos de uso.

Los actores pueden participar en una relación de generalización con otros actores.

Los actores pueden estar conectados a casos de uso solo por asociaciones.

Aquí tenemos un estudiante que interactúa con el registrador y el sistema de facturación a través de un caso de uso de "Registro para cursos".

MÁQUINA ESTATAL
“La vista de la máquina de estado describe el comportamiento dinámico de los objetos a lo largo del tiempo al modelar los ciclos de vida de los objetos de cada clase. Cada objeto
se trata como una entidad aislada que se comunica con el resto del mundo al detectar eventos y responder a ellos. Los eventos representan los tipos de cambios que los objetos
pueden detectar ... Cualquier cosa que pueda afectar a un objeto se puede caracterizar como un evento ". - El Manual de Referencia UML, [Rumbaugh, 99]

Un objeto debe estar en algún estado específico en un momento dado durante su ciclo de vida. Un objeto hace la transición de un estado a otro como resultado de algún evento
que lo afecta. Puede crear un diagrama de estado para cualquier clase, colaboración, operación o caso de uso en un modelo UML.
Solo puede haber un estado de inicio en un diagrama de estado, pero puede haber muchos estados intermedios y finales.
DIAGRAMA DE SECUENCIA
Un diagrama de secuencia es un diagrama de interacción que enfatiza el orden del tiempo de los mensajes. Muestra un conjunto de objetos y los mensajes enviados y recibidos
por esos objetos.
Gráficamente, un diagrama de secuencia es una tabla que muestra los objetos dispuestos a lo largo del eje X y los mensajes, ordenados a medida que aumenta el
tiempo, el eje Y. - La Guía del usuario de UML, [Booch, 99]

Un objeto en un diagrama de secuencia se representa como un cuadro con una línea discontinua que desciende de él.
La línea se llama línea de vida del objeto y representa la existencia de un objeto durante un período de tiempo.

Los mensajes se representan como flechas horizontales que pasan de un objeto a otro a medida que el tiempo avanza por las líneas de
vida del objeto. Las condiciones (como [check = “true”)) indican cuándo se pasa un mensaje.

Observe que la flecha inferior es diferente. La punta de la flecha no es sólida y no hay un mensaje que la
acompañe.
Esta flecha indica un retorno de un mensaje anterior, no un mensaje nuevo.

Un marcador de iteración, como * (como se muestra), o * [i = 1..n],

indica que un mensaje se repetirá como se indica.

DIAGRAMA DE COLABORACIÓN
Un diagrama de colaboración enfatiza la relación de los objetos que participan en una interacción. A diferencia de un diagrama de secuencia, no tiene que mostrar la línea de vida
de un objeto explícitamente en un diagrama de colaboración. La secuencia de eventos se indica mediante números de secuencia que preceden a los mensajes.
Los identificadores de objeto tienen el formato nombreobjeto: nombre de clase, y se puede omitir el nombre de objeto o el nombre de clase, y la colocación de los dos puntos
indica un nombre de objeto:, o un: nombre de clase.
Diagrama de colaboración-Diagrama de secuencia
Tanto un diagrama de colaboración como un diagrama de secuencia se derivan de la misma información en el metamodelo de UML, por lo que puede tomar un diagrama en una
forma y convertirlo en la otra. Son semánticamente equivalentes.
DIAGRAMA DE ACTIVIDAD
Un diagrama de actividad es esencialmente un diagrama de flujo, que muestra el flujo de control de actividad a actividad.
Use diagramas de actividad para especificar, construir y documentar la dinámica de una sociedad de objetos, o para modelar el flujo de control de una operación. Mientras que
los diagramas de interacción enfatizan el flujo de control de objeto en objeto, los diagramas de actividad enfatizan el flujo de control de actividad a actividad. Una actividad es
una ejecución continua no atómica dentro de una máquina de estado. - La Guía del usuario de UML, [Booch, 99]

DIAPOSITIVA # 3: DIAGRAMA DE CLASE.

INTRODUCCIÓN
• ¿Qué es la clase?
• Una clase es un plano que se utiliza para crear objetos. La clase define lo que el objeto puede hacer.
• ¿Qué es el diagrama de clase?
• Diagrama de clase ofrece la vista estática de una aplicación. Un diagrama de clase describe los tipos de objetos en el sistema y los diferentes tipos de relaciones que existen
entre ellos
• Diagrama de clase ayuda a construir el código para el desarrollo de aplicaciones de software.
DIAGRAMA DE LA CLASE: BENEFICIOS
• Diagrama de clase Ilustra modelos de datos incluso para sistemas de información muy complejos.
• Proporciona una descripción general de cómo se estructura la aplicación antes de estudiar el código real. Esto puede reducir fácilmente el tiempo de mantenimiento.
• Ayuda a comprender mejor los esquemas generales de una aplicación.
• Permite dibujar cuadros detallados que destacan el código requerido para ser programado
• Útil para los desarrolladores y otras partes interesadas.
DIAGRAMA DE CLASE: ELEMENTOS
Los elementos esenciales del diagrama de clases UML son:
• Nombre de la clase
• Atributos
• Operaciones

DIAGRAMA DE CLASE: RELACIONES

Hay principalmente tres tipos de relaciones en UML:
• Dependencias
• Generalizaciones
• Asociaciones
REALIZATION/IMPLEMENTATION
EJEMPLO:

BUENAS PRÁCTICAS DE DISEÑO DEL DIAGRAMA DE CLASE.

• Aquí hay algunos puntos que deben tenerse en cuenta al dibujar un diagrama de clase:
• El nombre dado al diagrama de clase debe ser significativo. Además, debe describir el aspecto real del sistema.
• La relación entre cada elemento debe ser identificada de antemano.
• La responsabilidad de cada clase debe ser identificada.
• Para cada clase, se debe especificar el número mínimo de propiedades. Por lo tanto, las propiedades no deseadas pueden complicar fácilmente el diagrama.
• Las notas del usuario deben incluirse siempre que necesite definir algún aspecto del diagrama. Al final del dibujo, debe ser comprensible para el equipo de desarrollo de software.
• Por último, antes de crear la versión final, el diagrama debe dibujarse en papel normal. Además, se debe volver a trabajar hasta que esté listo para su presentación final.

DIAPOSITIVA # 4: INSTANCIAS Y DIAGRAMAS DE OBJETOS.

ABSTRACCIONES E INSTANCIAS
• Abstracción: la esencia ideal de una cosa.
• Instancia: manifestación concreta de una abstracción.
- se puede aplicar un conjunto de operaciones y puede tener un estado que almacene los efectos de la operación
- No está solo, siempre atado a una abstracción.
OBJETOS
- Es sinónimo de instancia.
- Algo que ocupa espacio en el mundo real o conceptual.
- Es posible cambiar durante la abstracción de ese objeto.
- vive dentro del contexto de una operación, un componente o un nodo
LLAMADO, ANÓNIMO, MÚLTIPLE, E INSTANCIAS HUÉRFANAS ESTADO OBJETO
ELEMENTOS ESTÁNDAR
• Stereotypes • Estereotipos
– instanceOf - instancia de
– instantiate - instanciar
– become - convertirse en
– copy - copia
– transient - transitorio
MODELADO DE INSTANCIA CONCRETA MODELADO DE INSTANCIAS PROTOTÍPICAS

DIAGRAMAS DE OBJETOS
- Modelar las instancias de cosas contenidas en el diagrama de clase.
- un diagrama que muestra un conjunto de objetos y su relación en un momento determinado
- cubre un conjunto de instancias de las cosas que se encuentran en un diagrama de clase
- Expresa la parte estática de una interacción.
UN DIAGRAMA DE OBJETOS

CONTENIDO
• Contenidos particulares
- Objetos
- Enlaces
• Contenidos comunes
- Nombre, notas, paquete y subsistema.
USOS COMUNES
- modelar la vista de diseño estática o la vista de proceso estática de un sistema
- modelar la estructura de datos estática
- visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto con sus relaciones entre sí
MODELADO DE ESTRUCTURAS DE OBJETOS
PROPIEDADES DEL DIAGRAMA DE OBJETOS
- no es necesario que un solo diagrama de objetos capture todo sobre el diseño de un sistema o la vista de proceso.
- Reflejar algunos de los elementos concretos o prototípicos que viven en el sistema en ejecución.

DIAPOSITIVA # 5: DIAGRAMA DE OBJETOS.

INTRODUCCIÓN
• Los diagramas de objetos se derivan de diagramas de clase, por lo que los diagramas de objetos dependen de los diagramas de clase.
• Los diagramas de objetos representan una instancia de un diagrama de clase. Los conceptos básicos son similares para los diagramas de clase y los diagramas de objetos. Los
diagramas de objetos también representan la vista estática de un sistema, pero esta vista estática es una instantánea del sistema en un momento determinado.
OBJETO DEL DIAGRAMA DE OBJETO.
• El propósito de un diagrama debe entenderse claramente para implementarlo en la práctica. Los propósitos de los diagramas de objetos son similares a los diagramas de clase.
• La diferencia es que un diagrama de clase representa un modelo abstracto que consiste en clases y sus relaciones. Sin embargo, un diagrama de objetos representa una instancia
en un momento particular, que es de naturaleza concreta.
• Significa que el diagrama de objetos está más cerca del comportamiento real del sistema. El propósito es capturar la vista estática de un sistema en un momento particular.