Curso UML Emilio Avilés Ávila http://www.techmi.es

Workshop (20 horas) Workshop UML y Proceso Unificad para empresas y profesionales

Temario Introducción Diagramas Casos de Uso Diagramas de Clases Diagramas de Interacción Diagramas de Comportamiento Diagramas de implementación Otros diagramas Proceso Unificado

Introducción

Diagramas

Casos de Uso

Diagramas de Clases

Diagramas de Interacción

Diagramas de Comportamiento

Diagramas de implementación

Otros diagramas

Proceso Unificado

Tema 2 Diagramas

Objetivos Introducción Diagramas Casos de Uso Diagramas de Clases Diagramas de Interacción Diagramas de Comportamiento Diagramas de implementación Otros diagramas Proceso Unificado Conocer el modelo de casos de uso Identificar las partes de un CU (Actores) Relaciones entre CU include y extends. Diferencia entre Clase y Objeto. Partes de una clase UML. Técnicas para modelar clases. Elementos de un diagrama de clases. Diferenciar los 4 tipo de relaciones entre clases. Estereotipos.

Introducción

Diagramas

Casos de Uso

Diagramas de Clases

Diagramas de Interacción

Diagramas de Comportamiento

Diagramas de implementación

Otros diagramas

Proceso Unificado

Conocer el modelo de casos de uso

Identificar las partes de un CU (Actores)

Relaciones entre CU include y extends.

Diferencia entre Clase y Objeto.

Partes de una clase UML.

Técnicas para modelar clases.

Elementos de un diagrama de clases.

Diferenciar los 4 tipo de relaciones entre clases.

Estereotipos.

Tema 2.1 Casos de Uso

2.1 – Casos de Uso ¿Qué es un caso de uso? Un caso de uso es una secuencia de interacciones entre uno o varios actores y el sistema. Unidad discreta de interacción o de trabajo. Tiene lugar bajo ciertas circunstancias: Es iniciada por un actor . Se puede describir como una secuencia de actividades . Produce un resultado de valor observable para algún actor.

¿Qué es un caso de uso?

Un caso de uso es una secuencia de interacciones entre uno o varios actores y el sistema.

Unidad discreta de interacción o de trabajo.

Tiene lugar bajo ciertas circunstancias:

Es iniciada por un actor .

Se puede describir como una secuencia de actividades .

Produce un resultado de valor observable para algún actor.

2.1 – Casos de Uso

2.1 – Casos de Uso ¿Por qué utilizar Casos de Uso? Un caso de uso ayuda a contestar las siguientes preguntas: ¿ Quién hace qué? ¿ Cuándo lo hace? ¿ Qué actividades se realizan? ¿ Qué elementos del sistema se utilizan?

¿Por qué utilizar Casos de Uso?

Un caso de uso ayuda a contestar las siguientes preguntas:

¿ Quién hace qué?

¿ Cuándo lo hace?

¿ Qué actividades se realizan?

¿ Qué elementos del sistema se utilizan?

2.1 – Casos de Uso Alcance de caso de uso Determinar el alcance de un caso de uso consiste en identificar que elementos forman parte de dicho caso de uso. Tan importante como identificar lo que forma parte del caso de uso es identificar lo que NO forma parte del caso de uso.

Alcance de caso de uso

Determinar el alcance de un caso de uso consiste en identificar que elementos forman parte de dicho caso de uso.

Tan importante como identificar lo que forma parte del caso de uso es identificar lo que NO forma parte del caso de uso.

2.1 – Casos de Uso Ejemplo: R eserva de Billete

Ejemplo: R eserva de Billete

2.1 – Casos de Uso Ejercicio práctico Determinar cuales de las siguientes afirmaciones no caen dentro del alcance del caso de uso de reserva de billete aéreo …. Suerte!!!

Ejercicio práctico

Determinar cuales de las siguientes afirmaciones no caen dentro del alcance del caso de uso de reserva de billete aéreo

…. Suerte!!!

2.1 – Casos de Uso Elementos del Caso de Uso Descripción : Describe la funcionalidad que se construirá en el sistema propuesto. Relaciones : Inclusiones o Extensiones de funcionalidades con otros Caso de Uso.

Elementos del Caso de Uso

Descripción : Describe la funcionalidad que se construirá en el sistema propuesto.

Relaciones : Inclusiones o Extensiones de funcionalidades con otros Caso de Uso.

2.1 – Casos de Uso Descripción Caso de Uso Comentarios y notas describiendo CU. Requisitos : Que permite el CU al usuario Restricciones : reglas acerca de qué se puede y qué no se puede hacer Pre-condiciones, Post-condiciones o invariantes Escenarios : descripciones secuenciales de los pasos que se toman para llevar a cabo el CU. Pueden incluir escenarios base, excepcionales y caminos de proceso alternativos Atributos adicionales fase de implementación, número de versión, rango de complejidad, estereotipo y estado

Descripción Caso de Uso

Comentarios y notas describiendo CU.

Requisitos : Que permite el CU al usuario

Restricciones : reglas acerca de qué se puede y qué no se puede hacer

Pre-condiciones, Post-condiciones o invariantes

Escenarios : descripciones secuenciales de los pasos que se toman para llevar a cabo el CU.

Pueden incluir escenarios base, excepcionales y caminos de proceso alternativos

Atributos adicionales fase de implementación, número de versión, rango de complejidad, estereotipo y estado

2.1 – Casos de Uso Actores Representan elementos externos al sistema que colaboran con el mismo. Usuarios. Clientes. Otros sistemas. Dispositivos externos (p. ej. temporizadores). Tipos: Internos: Toman parte activa en el caso de uso. Externos: Disparan el caso de uso o reciben su salida.

Actores

Representan elementos externos al sistema que colaboran con el mismo.

Usuarios.

Clientes.

Otros sistemas.

Dispositivos externos (p. ej. temporizadores).

Tipos:

Internos: Toman parte activa en el caso de uso.

Externos: Disparan el caso de uso o reciben su salida.

2.1 – Casos de Uso Actores (II) Los actores no forman parte del sistema , sino que representan elementos que interactúan con él. Un actor puede introducir, recibir, o introducir y recibir información desde o hacia el sistema. Alcance o rol : Conjunto de CU a los que tiene acceso.

Actores (II)

Los actores no forman parte del sistema , sino que representan elementos que interactúan con él.

Un actor puede introducir, recibir, o introducir y recibir información desde o hacia el sistema.

Alcance o rol :

Conjunto de CU a

los que tiene acceso.

2.1 – Casos de Uso Diagramas de Caso de Uso Organizan los comportamientos y funcionalidad del sistema. Describe, posiblemente en lenguaje natural, una forma en que un `` actor '' del mundo real (persona, organización o sistema externo) interacciona con el modelo. Muestra requisitos funcionales . Escenario : Camino dentro de un CU. Muestra una combinación específica de condiciones en un caso de uso.

Diagramas de Caso de Uso

Organizan los comportamientos y funcionalidad del sistema.

Describe, posiblemente en lenguaje natural, una forma en que un `` actor '' del mundo real (persona, organización o sistema externo) interacciona con el modelo.

Muestra requisitos funcionales .

Escenario : Camino dentro de un CU.

Muestra una combinación específica de condiciones en un caso de uso.

2.1 – Casos de Uso

2.1 – Casos de Uso Relaciones entre CU CU – Actor: Asociación ``comunica'‘ (<<comunicates>>) En general navegable en ambas direcciones La dirección refleja quien inicia la comunicación. CU – CU: Pueden ser de dos tipos <<include>> (Incluye) <<extends>> (Extiende)

Relaciones entre CU

CU – Actor:

Asociación ``comunica'‘ (<<comunicates>>)

En general navegable en ambas direcciones

La dirección refleja quien inicia la comunicación.

CU – CU:

Pueden ser de dos tipos

<<include>> (Incluye)

<<extends>> (Extiende)

2.1 – Casos de Uso Relaciones Diagrama CU ``usa'' (<<include>>) Un CU puede incluir funcionalidad de otro como parte del procesamiento normal. Los CU incluidos se llamaran en el escenario base . Un CU puede ser incluido por uno o más Casos de Uso. Se reduce la duplicación de funcionalidad al factorizar el comportamiento común.

Relaciones Diagrama CU

``usa'' (<<include>>)

Un CU puede incluir funcionalidad de otro como parte del procesamiento normal.

Los CU incluidos se llamaran en el escenario base .

Un CU puede ser incluido por uno o más Casos de Uso.

Se reduce la duplicación de funcionalidad al factorizar el comportamiento común.

2.1 – Casos de Uso Ejemplo ``usa'' (<<include>>) El C.U. Incluido por si solo no tiene sentido , es decir, no podría ser llamado por un actor. Siempre es llamado por el C.U. que lo incluye (no es opcional).

Ejemplo ``usa'' (<<include>>)

El C.U. Incluido por si solo no tiene sentido , es decir, no podría ser llamado por un actor.

Siempre es llamado por el C.U. que lo incluye (no es opcional).

2.1 – Casos de Uso Relaciones Diagrama CU ``extiende'' (<<extends>>) Un CU puede extender comportamiento de otro caso de uso. Típicamente cuando ocurren escenarios excepcionales . Por ejemplo: Si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar orden>.

Relaciones Diagrama CU

``extiende'' (<<extends>>)

Un CU puede extender comportamiento de otro caso de uso.

Típicamente cuando ocurren escenarios excepcionales .

Por ejemplo:

Si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar orden>.

2.1 – Casos de Uso Ejemplo <<extends>> Un caso de uso extiende a otro cuando agrega tareas adicionales al primero. Los puntos de extensión pueden ir unidos a una condición que debe cumplirse para indicar la extensión (Factura > 300)

Ejemplo <<extends>>

Un caso de uso extiende a otro cuando agrega tareas adicionales al primero.

Los puntos de extensión pueden ir unidos a una condición que debe cumplirse para indicar la extensión (Factura > 300)

2.1 – Casos de Uso Resumen: Relaciones Diagrama CU ``comunica'' (<<communicates>>): Relación Actor – CU. Denota participación del actor en el CU. ``usa'' (<<include>>) Relación de dependencia de dos CU. Denota inclusión de comportamiento de 1 en otro. Repetición del comportamiento del CU. ``extiende'' (<< extends>>): Relación de dependencia de dos CU. Denota especialización de 1 en otro. Variación del comportamiento normal del CU.

Resumen: Relaciones Diagrama CU

``comunica'' (<<communicates>>):

Relación Actor – CU.

Denota participación del actor en el CU.

``usa'' (<<include>>)

Relación de dependencia de dos CU.

Denota inclusión de comportamiento de 1 en otro.

Repetición del comportamiento del CU.

``extiende'' (<< extends>>):

Relación de dependencia de dos CU.

Denota especialización de 1 en otro.

Variación del comportamiento normal del CU.

2.1 – Casos de Uso Ejercicio práctico Modelar el diagrama de Casos de Usos de una maquina expendedora de café Representar los CU Representar los Actores Representar todas las posibles Relaciones …. Suerte!!!

Ejercicio práctico

Modelar el diagrama de Casos de Usos de una maquina expendedora de café

Representar los CU

Representar los Actores

Representar todas las posibles Relaciones

…. Suerte!!!

2.1 – Casos de Uso

2.1 – Casos de Uso Modelo Casos de Usos Combinación de Casos de Uso y sus diagramas. Suelen venir acompañado de un Glosario .

Modelo Casos de Usos

Combinación de Casos de Uso y sus diagramas.

Suelen venir acompañado de un Glosario .

2.1 – Casos de Uso Herencia vs Extends Además de las relaciones entre CU y Actor, y las dependencias de entre CU ( <<include>> y <<extends>>) pueden existir relaciones de herencia . NO CONFUNDIR! Generalización (Herencia): El caso de uso derivado (particular o heredero) puede modificar alguna de las tareas del caso de uso base (general). Extensión: El caso de uso que extiende NO puede modificar las tareas del caso de uso del cual se extiende. Solamente puede agregar tareas nuevas en los puntos de extensión.

Herencia vs Extends

Además de las relaciones entre CU y Actor, y las dependencias de entre CU ( <<include>> y <<extends>>) pueden existir relaciones de herencia .

NO CONFUNDIR!

Generalización (Herencia):

El caso de uso derivado (particular o heredero) puede modificar alguna de las tareas del caso de uso base (general).

Extensión:

El caso de uso que extiende NO puede modificar las tareas del caso de uso del cual se extiende. Solamente puede agregar tareas nuevas en los puntos de extensión.

2.1 – Casos de Uso Ejemplo Herencia en Actores Polimorfismo

Ejemplo Herencia en Actores Polimorfismo

Tema 2.2 Diagrama de Clases

2.2 – Diagrama de Clases Previo… Objetos Representación de una entidad: Conceptual o real. Con unos límites definidos. Con significado dentro del modelo. Cada objeto se caracteriza por: Identidad Estado ( propiedades o atributos) Comportamiento (Métodos o Operaciones)

Previo… Objetos

Representación de una entidad:

Conceptual o real.

Con unos límites definidos.

Con significado dentro del modelo.

Cada objeto se caracteriza por:

Identidad

Estado ( propiedades o atributos)

Comportamiento (Métodos o Operaciones)

2.2 – Diagrama de Clases Clases Descripción de un grupo de objetos con: Propiedades comunes (atributos). Comportamiento común (operaciones). Relaciones comunes. Por lo tanto un clase será una plantilla ( template) para la creación de objetos: Cada objeto de dicha clase será una instancia de ella. No pudiendo ser instancia de más de una clase.

Clases

Descripción de un grupo de objetos con:

Propiedades comunes (atributos).

Comportamiento común (operaciones).

Relaciones comunes.

Por lo tanto un clase será una plantilla ( template) para la creación de objetos:

Cada objeto de dicha clase será una instancia de ella.

No pudiendo ser instancia de más de una clase.

2.2 – Diagrama de Clases Diagrama de Clases: Introducción Diagrama que muestra una colección de elementos declarativos (estáticos) de un modelo, como clases y tipos, junto con sus contenidos y relaciones . Son la espina dorsal de UML. Elementos que forman un Diagrama de clases Clases Relaciones

Diagrama de Clases: Introducción

Diagrama que muestra una colección de elementos declarativos (estáticos) de un modelo, como clases y tipos, junto con sus contenidos y relaciones .

Son la espina dorsal de UML.

Elementos que forman un Diagrama de clases

Clases

Relaciones

2.2 – Diagrama de Clases Diagrama de Clases: Perspectivas Conceptual : Permite representar los conceptos del dominio. Especificación: Cuando se trata de representar las interfaces del software y no el software en sí. Implementación: Es en esta perspectiva donde realmente tenemos clases , siendo ésta la perspectiva más utilizada.

Diagrama de Clases: Perspectivas

Conceptual :

Permite representar los conceptos del dominio.

Especificación:

Cuando se trata de representar las interfaces del software y no el software en sí.

Implementación:

Es en esta perspectiva donde realmente tenemos clases , siendo ésta la perspectiva más utilizada.

2.2 – Diagrama de Clases Clase en UML

Clase en UML

2.2 – Diagrama de Clases Clase en UML Tienen un nombre que las distingue de otras clases. Al dibujar una clase NO hay por qué representar toda su información . Los estereotipos permiten organizar la información de una clase.

Clase en UML

Tienen un nombre que las distingue de otras clases.

Al dibujar una clase NO hay por qué representar toda su información .

Los estereotipos permiten organizar la información de una clase.

2.2 – Diagrama de Clases Clase en UML: Visibilidad public +: Cualquier clase externa con visibilidad hacia la clase dada puede utilizar la característica (ya se atributo u operación). protected #: Cualquier descendiente de la clase puede utilizar la característica. private -: Sólo el propio clasificador puede utilizar la característica.

Clase en UML: Visibilidad

public +: Cualquier clase externa con visibilidad hacia la clase dada puede utilizar la característica (ya se atributo u operación).

protected #: Cualquier descendiente de la clase puede utilizar la característica.

private -: Sólo el propio clasificador puede utilizar la característica.

2.2 – Diagrama de Clases Clase en UML: Alcance Característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase. instancia : Cada instancia de la clase tiene su propio valor. clasificador : Sólo hay un valor para todas las instancias del clasificador. Se denota subrayando la característica.

Clase en UML: Alcance

Característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase.

instancia : Cada instancia de la clase tiene su propio valor.

clasificador : Sólo hay un valor para todas las instancias del clasificador.

Se denota subrayando la característica.

2.2 – Diagrama de Clases Clase en UML: Atributos Inicialización Se puede especificarse un valor inicial y un conjunto de propiedades del atributo.

Clase en UML: Atributos Inicialización

Se puede especificarse un valor inicial y un conjunto de propiedades del atributo.

2.2 – Diagrama de Clases Clase en UML: Operaciones Donde cada uno de los parámetros en parameter list se denota igual que un atributo. Los demás elementos son los mismos que encontramos en la notación de un atributo.

Clase en UML: Operaciones

Donde cada uno de los parámetros en parameter list se denota igual que un atributo.

Los demás elementos son los mismos que encontramos en la notación de un atributo.

2.2 – Diagrama de Clases Clase en UML: Alcance Característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase. instancia : Cada instancia de la clase tiene su propio valor. clasificador : Sólo hay un valor para todas las instancias del clasificador. Se denota subrayando la característica.

Clase en UML: Alcance

Característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase.

instancia : Cada instancia de la clase tiene su propio valor.

clasificador : Sólo hay un valor para todas las instancias del clasificador.

Se denota subrayando la característica.

2.2 – Diagrama de Clases Clase en UML: Paramétrica Se corresponde con el concepto de clases molde ( template ) en C++ o genéricos Java Ejemplo La clase Lista que utiliza un parámetro formal Tipo Pudiendo representar una lista de diferentes tipos de objetos dependiendo del valor del parámetro

Clase en UML: Paramétrica

Se corresponde con el concepto de clases molde ( template ) en C++ o genéricos Java

Ejemplo

La clase Lista que utiliza un parámetro formal Tipo

Pudiendo representar una lista de diferentes tipos de objetos dependiendo del valor del parámetro

2.2 – Diagrama de Clases Técnicas para modelar Clases (I) Modelado del vocabulario Identificar las palabras que utilizan los usuarios o programadores para describir el problema o la solución. Identificar responsabilidades para cada abstracción identificar. Proporcionar atributos y operaciones para cada clase.

Técnicas para modelar Clases (I)

Modelado del vocabulario

Identificar las palabras que utilizan los usuarios o programadores para describir el problema o la solución.

Identificar responsabilidades para cada abstracción identificar.

Proporcionar atributos y operaciones para cada clase.

2.2 – Diagrama de Clases Técnicas para modelar Clases (II) Modelado de Responsabilidades Identificar un conjunto de clases que colaboren entre ellas para llevar a cabo algún comportamiento y sus responsabilidades. Dividir las clases con demasiadas responsabilidades y agrupar las que tienen pocas, verificando que no hay solapamiento de responsabilidades. Verificar la granularidad de las responsabilidades.

Técnicas para modelar Clases (II)

Modelado de Responsabilidades

Identificar un conjunto de clases que colaboren entre ellas para llevar a cabo algún comportamiento y sus responsabilidades.

Dividir las clases con demasiadas responsabilidades y agrupar las que tienen pocas, verificando que no hay solapamiento de responsabilidades.

Verificar la granularidad de las responsabilidades.

2.2 – Diagrama de Clases Relaciones: Origen Todo los sistemas se construyen a partir de muchas clases y objetos para lograr ofrecer el comportamiento deseado. Esto implica una colaboración entre ellos que impone la existencia de unas relaciones.

Relaciones: Origen

Todo los sistemas se construyen a partir de muchas clases y objetos para lograr ofrecer el comportamiento deseado.

Esto implica una colaboración entre ellos que impone la existencia de unas relaciones.

2.2 – Diagrama de Clases Relaciones: Tipos Asociación : Relación semántica. Composición : Relación de Composición. Agregación: Relación de pertenencia Dependencia : Relación de Necesidad. Generalización : Relación taxonómica.

Relaciones: Tipos

Asociación : Relación semántica.

Composición : Relación de Composición.

Agregación: Relación de pertenencia

Dependencia : Relación de Necesidad.

Generalización : Relación taxonómica.

2.2 – Diagrama de Clases Relación de Asociación Relación semántica entre instancias con tipo.

Relación de Asociación

Relación semántica entre instancias con tipo.

2.2 – Diagrama de Clases Relación de Asociación No es un flujo de datos sino una relación estructural entre objetos instanciados. “ Los objetos de una clase conocen de la otra” Desde el punto de vista conceptual representan relaciones. especificación representan responsabilidades. Implementación representan punteros.

Relación de Asociación

No es un flujo de datos sino una relación estructural entre objetos instanciados.

“ Los objetos de una clase conocen de la otra”

Desde el punto de vista

conceptual representan relaciones.

especificación representan responsabilidades.

Implementación representan punteros.

2.2 – Diagrama de Clases Relación de Asociación : Notación Verbo activo o frase verbal que recoge el significado de la asociación Rol opcional que denota propósito Multiplicidad (número de objetos) Navegabilidad : Sentido de la dirección.

Relación de Asociación : Notación

Verbo activo o frase verbal que recoge el significado de la asociación

Rol opcional que denota propósito

Multiplicidad (número de objetos)

Navegabilidad : Sentido de la dirección.

2.2 – Diagrama de Clases Relación de Agregación Relación de Composición : Una clase está compuesta de otras. Relación de Agregación : Una clase tiene otra clase de otras.

Relación de Agregación

Relación de Composición : Una clase está compuesta de otras.

Relación de Agregación : Una clase tiene otra clase de otras.

2.2 – Diagrama de Clases Relación Asociación: Cualificadores En ocasiones, la asociación no es mediante una referencia, sino por un campo clave o token. Por tanto para acceder al objeto habrá que implementar alguna función de búsqueda.

Relación Asociación: Cualificadores

En ocasiones, la asociación no es mediante una referencia, sino por un campo clave o token.

Por tanto para acceder al objeto habrá que implementar alguna función de búsqueda.

2.2 – Diagrama de Clases Relación de Agregación Un asociación representa un relación estructural por igual, al mismo nivel. Un agregación es una asociación especializada por el cual un todo se relaciona con sus partes . También se la suele denominar como la relación ``parte de'' UML ofrece una variedad más fuerte de agregación llamada composición. Los objetos parte viven y mueren con el todo .

Relación de Agregación

Un asociación representa un relación estructural por igual, al mismo nivel.

Un agregación es una asociación especializada por el cual un todo se relaciona con sus partes .

También se la suele denominar como la relación ``parte de''

UML ofrece una variedad más fuerte de agregación llamada composición.

Los objetos parte viven y mueren con el todo .

2.2 – Diagrama de Clases Relación de Dependencia Un elemento del modelo necesita a otro para su implementación o especificación. El cambio en uno puede afectar al otro.

Relación de Dependencia

Un elemento del modelo necesita a otro para su implementación o especificación.

El cambio en uno puede afectar al otro.

2.2 – Diagrama de Clases Relación de Dependencia Va más ligada a operaciones entre Clases. Una clase utiliza otra como argumento de una de sus operaciones. También se encuentran relaciones de dependencia entre paquetes. Si un paquete A depende de un paquete B , entonces hay una o más clases en el paquete A que inician comunicación con una o más clases públicas del paquete B .

Relación de Dependencia

Va más ligada a operaciones entre Clases.

Una clase utiliza otra como argumento de una de sus operaciones.

También se encuentran relaciones de dependencia entre paquetes.

Si un paquete A depende de un paquete B , entonces hay una o más clases en el paquete A que inician comunicación con una o más clases públicas del paquete B .

2.2 – Diagrama de Clases Relación de Generalización Relación taxonómica entre un clasificador más general y otro más específico. El específico hereda las características y es instancia indirecta del general.

Relación de Generalización

Relación taxonómica entre un clasificador más general y otro más específico.

El específico hereda las características y es instancia indirecta del general.

2.2 – Diagrama de Clases Relación de Generalización Una clase comparte estructura y/o comportamiento con otras clases. Superclase: Clase que guarda la información Subclase: Descendientes de la superclase. Hereda todos los atributos, operaciones y relaciones definidos en su superclase. Pueden ampliar información de la superclase. Puede tener su propia implementación de una operación de la superclase ( Polimorfismo)

Relación de Generalización

Una clase comparte estructura y/o comportamiento con otras clases.

Superclase: Clase que guarda la información

Subclase: Descendientes de la superclase.

Hereda todos los atributos, operaciones y relaciones definidos en su superclase.

Pueden ampliar información de la superclase.

Puede tener su propia implementación de una operación de la superclase ( Polimorfismo)

2.2 – Diagrama de Clases Generalización vs Especialización Generalización: Proporciona la capacidad de crear superclases que encapsulan la estructura y el comportamiento común a varias clases. Especialización: Proporciona la capacidad de crear subclases que representan refinamientos de una superclase, generalmente añadiendo estructura y comportamiento a las nuevas subclases. Las operaciones heredadas pueden ser rescritas La subclase no debería proporcionar una estructura o comportamiento menor que el de su superclase.

Generalización vs Especialización

Generalización:

Proporciona la capacidad de crear superclases que encapsulan la estructura y el comportamiento común a varias clases.

Especialización:

Proporciona la capacidad de crear subclases que representan refinamientos de una superclase, generalmente añadiendo estructura y comportamiento a las nuevas subclases.

Las operaciones heredadas pueden ser rescritas

La subclase no debería proporcionar una estructura o comportamiento menor que el de su superclase.

2.2 – Diagrama de Clases Herencia: Conceptos avanzados. Clases Abstractas : Sin instancias directas. En UML se especifica que una clase es abstracta escribiendo su nombre en cursiva . Clase Final : no puede tener descendentes. En UML se utiliza para ello la restricción {leaf}. Clase sin antecesores Asociando la restricción {root} a una clase. Restringir el número de instancias Su multiplicidad que será un número cardinal en la esquina superior derecha del icono de la clase.

Herencia: Conceptos avanzados.

Clases Abstractas : Sin instancias directas.

En UML se especifica que una clase es abstracta escribiendo su nombre en cursiva .

Clase Final : no puede tener descendentes.

En UML se utiliza para ello la restricción {leaf}.

Clase sin antecesores

Asociando la restricción {root} a una clase.

Restringir el número de instancias

Su multiplicidad que será un número cardinal en la esquina superior derecha del icono de la clase.

2.2 – Diagrama de Clases Estereotipos Permite “ extender ” el lenguaje UML para los diagramas de clases. Asppage, vista, modelo, controlador, persistencia… Se representan por <<estereotipo>> También son aplicables a la relación (por ejemplo, para indicar patrones como el Observer).

Estereotipos

Permite “ extender ” el lenguaje UML para los diagramas de clases.

Asppage, vista, modelo, controlador, persistencia…

Se representan por <<estereotipo>>

También son aplicables a la relación (por ejemplo, para indicar patrones como el Observer).

2.2 – Diagrama de Clases Estereotipos: Tipos Comunes Entidad ( entity ): reflejar entidades del mundo real modela la información de larga vida y su comportamiento asociado . Frontera ( boundary ): maneja comunicaciones entre el entorno del sistema y el sistema Control ( control ) comportamiento secuenciado específico de uno o varios CU Utilidad ( utility ) Excepción ( exception ).

Estereotipos: Tipos Comunes

Entidad ( entity ):

reflejar entidades del mundo real

modela la información de larga vida y su comportamiento asociado .

Frontera ( boundary ): maneja comunicaciones entre el entorno del sistema y el sistema

Control ( control ) comportamiento secuenciado específico de uno o varios CU

Utilidad ( utility )

Excepción ( exception ).

2.2 – Diagrama de Clases Estereotipos: <<Interfaz>> Cuando una clase trabaja con objetos que deben implementar una interfaz. Puede indicar con una relación de dependencia con la interfaz y el estereotipo <<uses>> o la forma alternativa indicada a continuación.

Estereotipos: <<Interfaz>>

Cuando una clase trabaja con objetos que deben implementar una interfaz.

Puede indicar con una relación de dependencia con la interfaz y el estereotipo <<uses>> o la forma alternativa indicada a continuación.

2.1 – Casos de Uso Ejercicio práctico Dado el siguiente modelo conceptual Representar como sería el Diagrama de Clases correspondiente: …. Suerte!!!

Ejercicio práctico

Dado el siguiente modelo conceptual

Representar como sería el Diagrama de Clases correspondiente:

…. Suerte!!!

2.2 – Diagrama de Clases Solución al Ejercicio práctico

Solución al Ejercicio práctico

2.1 – Casos de Uso Ejercicio práctico Modelar el diagrama de clases: Una aplicación necesita almacenar información sobre empresas, sus empleados y sus clientes. Ambos se caracterizan por su nombre y edad. Los empleados tienen un sueldo bruto, los empleados que son directivos tienen una categoría, así como un conjunto de empleados subordinados. De los clientes además se necesita conocer su teléfono de contacto. La aplicación necesita mostrar los datos de empleados y clientes. …. Suerte!!!

Ejercicio práctico

Modelar el diagrama de clases:

Una aplicación necesita almacenar información sobre empresas, sus empleados y sus clientes.

Ambos se caracterizan por su nombre y edad.

Los empleados tienen un sueldo bruto, los empleados que son directivos tienen una categoría, así como un conjunto de empleados subordinados.

De los clientes además se necesita conocer su teléfono de contacto.

La aplicación necesita mostrar los datos de empleados y clientes.

…. Suerte!!!

2.2 – Diagrama de Clases Posible Solución al Ejercicio

Posible Solución al Ejercicio

2.1 – Casos de Uso Ejercicio práctico Modelar el diagrama de clases de un cliente que se va de cañas y le ponen una tapa. Debe de pedir al menos una caña (bebida) para que le pongan. Puede pagar con tarjeta de crédito como en efectivo. …. Suerte!!!

Ejercicio práctico

Modelar el diagrama de clases de un cliente que se va de cañas y le ponen una tapa.

Debe de pedir al menos una caña (bebida) para que le pongan.

Puede pagar con tarjeta de crédito como en efectivo.

…. Suerte!!!

2.2 – Diagrama de Clases Posible Solución al Ejercicio

Posible Solución al Ejercicio

2.1 – Casos de Uso Ejercicio práctico: Biblioteca Una biblioteca tiene copias de libros. Estos últimos se caracterizan por su nombre, tipo (novela, teatro, poesía, ensayo), editorial, año y autor. Los autores se caracterizan por su nombre, nacionalidad y fecha de nacimiento. Cada copia tiene un identificador, y puede estar en la biblioteca, prestada, con retraso o en reparación. Los lectores pueden tener un máximo de 3 libros en préstamo. Cada libro se presta un máximo de 30 días, por cada día de retraso, se impone una “multa” de dos días sin posibilidad de coger un nuevo libro. Realiza un diagrama de clases y añade los métodos necesarios para realizar el préstamo y devolución de libros. … . Suerte!!!

Ejercicio práctico: Biblioteca

Una biblioteca tiene copias de libros. Estos últimos se

caracterizan por su nombre, tipo (novela, teatro, poesía,

ensayo), editorial, año y autor.

Los autores se caracterizan por su nombre, nacionalidad

y fecha de nacimiento.

Cada copia tiene un identificador, y puede estar en la

biblioteca, prestada, con retraso o en reparación.

Los lectores pueden tener un máximo de 3 libros en

préstamo.

Cada libro se presta un máximo de 30 días, por cada día

de retraso, se impone una “multa” de dos días sin

posibilidad de coger un nuevo libro.

Realiza un diagrama de clases y añade los métodos

necesarios para realizar el préstamo y devolución de

libros.

… . Suerte!!!

2.2 – Diagrama de Clases Posible Solución a la biblioteca

Posible Solución a la biblioteca

2.1 – Casos de Uso Ejercicio práctico: Redes de ordenadores Especificar un diagrama de clases que describa redes de ordenadores. Los elementos que se pueden incluir en la red son: Servidor, PC, Impresora. Hub, Cable de red. Los PCs pueden conectarse con un único Hub, los servidores con uno o varios. Los Servidores y PCs pueden generar mensajes, con una cierta longitud. Los Hubs tienen un número de puertos, algunos de los cuales puede usarse para conectar con otros Hubs. Tienen cierta probabilidad de “perder” mensajes. Las impresoras pueden averiarse, con cierta probabilidad, durante cierto tiempo.

Ejercicio práctico: Redes de ordenadores

Especificar un diagrama de clases que describa redes de ordenadores.

Los elementos que se pueden incluir en la red son:

Servidor, PC, Impresora.

Hub, Cable de red.

Los PCs pueden conectarse con un único Hub, los servidores con uno o varios.

Los Servidores y PCs pueden generar mensajes, con una cierta longitud.

Los Hubs tienen un número de puertos, algunos de los cuales puede usarse para conectar con otros Hubs. Tienen cierta probabilidad de “perder” mensajes.

Las impresoras pueden averiarse, con cierta probabilidad, durante cierto tiempo.

2.2 – Diagrama de Clases Posible Solución a la Redes

Posible Solución a la Redes

Conclusiones Introducción Diagramas Casos de Uso Diagramas de Clases Diagramas de Interacción Diagramas de Comportamiento Diagramas de implementación Otros diagramas Proceso Unificado Conocer el modelo de casos de uso Identificar las partes de un CU (Actores) Relaciones entre CU include y extends. Diferencia entre Clase y Objeto. Partes de una clase UML. Técnicas para modelar clases. Elementos de un diagrama de clases. Diferenciar los 4 tipo de relaciones entre clases. Estereotipos.

Introducción

Diagramas

Casos de Uso

Diagramas de Clases

Diagramas de Interacción

Diagramas de Comportamiento

Diagramas de implementación

Otros diagramas

Proceso Unificado

Conocer el modelo de casos de uso

Identificar las partes de un CU (Actores)

Relaciones entre CU include y extends.

Diferencia entre Clase y Objeto.

Partes de una clase UML.

Técnicas para modelar clases.

Elementos de un diagrama de clases.

Diferenciar los 4 tipo de relaciones entre clases.

Estereotipos.

Referencias Guía básica Curso UML.pdf Tutorial Sparx http://www.sparxsystems.com.ar/resources/tutorial/use_case_model.html http://www.sparxsystems.com.ar/resources/tutorial/logical_model.html

Guía básica Curso UML.pdf

Tutorial Sparx

http://www.sparxsystems.com.ar/resources/tutorial/use_case_model.html

http://www.sparxsystems.com.ar/resources/tutorial/logical_model.html