Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf ·...

84
Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML

Transcript of Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf ·...

Page 1: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

Ingeniería del Software Orientado a ObjetosUnidad 6: Vistas del UML

Page 2: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

El UML

Es un lenguaje estándar para escribir planos del software.

El UML es sólo un lenguaje y como tal es parte de un método de desarrollo de software.

Es independiente del proceso de software.

Page 3: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

UML

El UML es un lenguaje para:VisualizarEspecificarConstruirDocumentarLos artefactos de un sistema de software

Page 4: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vistas del UML

Vista Estructural

Vista deImplementación

Vista deAmbiente

Vista delComportamiento

Vista delUsuario

Page 5: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vista del Usuario (User View) Representa el problema y la solución

desde la perspectiva de los individuos a cuyo problema se enfoca la solución.

Page 6: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vista Estructural (Structural View) Incluye los aspectos estáticos o

estructurales del problema y la solución. También se conoce como la vista estática

o lógica.

Page 7: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vista del Comportamiento (Behavioral View) Incluye los aspectos dinámicos del

problema y la solución. También se conoce como la vista

dinámica, de procesos, concurrente o colaborativa.

Page 8: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vista de Implementación (Implementation View) Incluye los aspectos estructurales y de

comportamiento de la realización de la solución.

Esta vista se conoce también como la vista de componentes o de desarrollo.

Page 9: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vista de Ambiente (Environment View) Abarca los aspectos estructurales y de

comportamiento del dominio en el cual la solución debe ser realizada.

También se conoce como vista de instalación o vista física.

Page 10: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Vistas 4+1 del UML

Vista Lógica

Vista deDesarrollo

Vista FísicaVista de Procesos

Escenarios

Page 11: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

6.2 Diagramas del UML

Page 12: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Casos de Uso

Autentifica Usuario

Maestro Registra Calificación

Alumno Consulta Kardex

<<include>>

<<include>>

Bloquea Cuenta

<<extend>>

Page 13: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Casos de Uso

Es una secuencia de transacciones realizadas por un sistema que arrojan un resultado medible de valores para un actor particular

Representan la funcionalidad que provee el sistema.

Page 14: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Casos de Uso

Modelan un diálogo entre los actores y el sistema.

La colección de los casos de uso de un sistema constituyen todas las formas definidas en las que el sistema puede ser utilizado.

Page 15: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Actores

Los actores NO son parte del sistema, representan cualquier ente que debe interactuar con el sistema. Un actor puede:Sólo captar información en el sistema.Sólo recibir información del sistema.Captar y recibir información al y desde el

sistema.

Page 16: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Relaciones entre Casos de Uso

Una relación de asociación puede existir entre un actor y un caso de uso.

Este tipo de relaciones se denominan asociaciones de comunicación ya que representan la comunicación entre un actor y un caso de uso.

UML define cuatro tipos de relación en los Diagramas de Casos de Uso.

Page 17: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Relación de comunicación

Actor C aso de U so

Page 18: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Relación de Inclusión (include)

Se da entre dos casos de uso cuando uno de ellos representa funcionalidad que se comparte con otros casos de uso.

La asociación se representa con una flecha que va desde el caso de uso base hacia el caso de uso incluido.

Caso de Uso Origen C aso de U so Desti no

<<include>>

Page 19: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Relación de extensión (extend)

Se usa para mostrar: Comportamiento opcional. Comportamiento que se ejecuta sólo bajo ciertas

circunstancias, tales como disparar una alarma. Varios flujos diferentes pueden ser ejecutados

basados en la selección del actor. Se representa como una flecha que apunta del

caso de uso extendido al caso de uso base

Caso de uso base Caso de Uso extendido

<<extend>>

Page 20: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Casos de Uso

Documenta el comportamiento del sistema en desarrollo.

Muestra las funciones que el sistema debe cumplir, su entorno (actores) y las relaciones entre los casos de uso y los actores (diagrama de casos de uso).

El papel más importante de un modelo de casos de uso es el de comunicar.

Page 21: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Ejemplo de Diagrama de Casos de Uso

Autentifica Usuario

Maes tro Registra Calificación

Alumno Consulta Kardex

<<include>>

<<include>>

Bloquea Cuenta

<<extend>>

Autentifica con password

Autentifica con retina

Page 22: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Actividades

El sistema pide usuario y password

El sistema valida al alumno

válido

El sistema despliega el kardex

intentos

El sistema bloquea la cuenta del alumno

[ intentos <= 3 ]

[ intentos > 3 ]

Page 23: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Actividades

Los diagramas de actividades representan la dinámica del sistema.

Muestran el flujo del control en el sistema conforme pasa de una actividad a otra, cuales actividades pueden ser llevadas a cabo en paralelo y cualquier trayectoria alternativa del flujo.

Page 24: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Actividades

En la etapa inicial (inception) del proyecto, los diagramas de actividades pueden ser creados para representar el flujo entre casos de uso, o para representar el flujo dentro de un caso de uso en particular.

En las etapas avanzadas del proyecto, los diagramas de actividades pueden ser creados para mostrar el flujo de una operación en el diseño del sistema.

Page 25: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Actividades

Actividad inicial

Actividad final

Barras de sincronización

Page 26: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Actividades con Marcos de Responsabilidad

Page 27: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Ejemplo de diagrama de actividades

El sistema pide usuario y password

El sistema valida al alumno

válido

El sistema despliega el kardex

intentos

El sistema bloquea la cuenta del alumno

[ intentos <= 3 ]

[ intentos > 3 ]

Page 28: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de ClasesPersona

NombreDireccion

obtenDireccion()

Maestro

materiaCursadamateriacalificacion

registraCalificacion()

calif ica

Alumno

Kardex

0..n

1

1

tiene

1

1

0..n

Page 29: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Clases

Es un diagrama que muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones.

Gráficamente, un diagrama de clases es una colección de vértices y arcos.

Page 30: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Utilidad de los Diagramas de Clase

Se utilizan para modelar la vista de diseño estático de un sistema.

Por lo regular se utilizan para una de las siguientes cosas:Modelar el vocabulario del sistemaModelar colaboraciones simplesModelar el esquema lógica de la BD

Page 31: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Modelado del vocabulario del Sistema Involucra tomar decisiones acerca de

cuáles abstracciones son parte del sistema en consideración y cuáles caen fuera de sus fronteras.

Se usan los diagramas de clase para especificar estas abstracciones y sus responsabilidades.

Page 32: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Modelado de colaboraciones simples Una colaboración es una sociedad de

clases, interfaces y otros elementos que trabajan en conjunto para proveer algún comportamiento cooperativo que es mayor que la suma de sus elementos.

Los diagramas de clases se utilizan para visualizar y especificar este conjunto de clases y sus relaciones.

Page 33: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Modelado de esquema lógico de BD El esquema de una BD es el equivalente

al plano de un edificio. Cuando se requiere almacenar

información persistente en una base de datos, se pueden utilizar los diagramas de clase para construir los planos (el esquema).

Page 34: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Relaciones entre clases

Dependencia Generalización Asociación Realización

Page 35: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Dependencia

Es una relación de uso, la cual establece que un cambio en la especificación de una cosa puede afectar a otra que la utiliza, pero no necesariamente en el caso contrario.

Se utilizan cuando es necesario denotar que una clase utiliza a otra.

Una relación de dependencia se representa como una línea punteada que apunta del cliente al proveedor.

Page 36: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Dependencia

Por lo regular se usarán dependencias en el contexto de clases para mostrar que una clase usa a otra clase como argumento en la firma de alguna operación.

Page 37: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Generalización

Es una relación entre una cosa general (llamada la superclase o padre) y una clase más específica de esa cosa.

Comúnmente llamada relación “es un tipo de”. Significa que los objetos de los hijos pueden ser

usados en cualquier parte que el padre sea requerido, pero no en el caso contrario.

Page 38: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Generalización

Un hijo hereda los atributos y operaciones de sus padres.

A veces el hijo tiene atributos y operaciones adicionales.

Una operación del hijo que tiene la misma firma que una operación del padre sobreescribe esta última, esto se conoce como polimorfismo.

Page 39: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...GeneralizaciónVehiculo

combustible : String

Vehiculo(tipoCombustible : String)getCombustible() : StringsetCombust ible() : Integervirar(rumbo : String) : Boolean

Barco Automovil

• Una clase puede tener cero, uno o más padres.

• Una clase que no tiene padres y tiene uno o más hijo se conoce como clase raíz o clase base.

• Una clase sin hijos es una clase hoja.

• Una clase con un solo padre se dice que usa herencia simple.

• Una clase con más de un padre se dice que usa herencia múltiple.

Page 40: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Asociación

Es una relación estructural que especifica que los objetos de una cosa están conectados a objetos de otra.

Es una conexión semántica bidireccional entre clases.

No es un flujo de datos como se define en el análisis y diseño estructurado, los datos pueden fluir en cualquier dirección a través de la asociación.

Page 41: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación

Una asociación entre clases significa que existe una liga entre los objetos de las clases asociadas.

Dada una asociación que conecta dos clases, se puede navegar de un objeto de una clase a un objeto de la otra clase y viceversa.

Una clase puede tener asociaciones así misma.

Page 42: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación

• Una clase se puede asociar con una, dos o más clases

• Una asociación que conecta exactamente dos clases es llamada asociación binaria.

Page 43: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...AsociaciónAdornosLas asociaciones pueden tener nombre. El nombre de una asociación por lo regular se representa con un verbo.

Page 44: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación•En una asociación se pueden representar los roles que cada clase desempeña.

•Los roles son sustantivos que describen el papel de la clase en la asociación

Page 45: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación

Restricciones Es probable que las asociaciones se puedan dar bajo

ciertas restricciones, estas se pueden representar mediante una condición encerrada entre llaves del lado de la clase que tiene que cumplirla.

Page 46: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación

Multiplicidad Indica la cantidad de objetos de una clase que se

relacionan con uno o más objetos de la clase asociada.

Se representa mediante un valor o intervalo de valores a un lado de la clase, que indica el número de ocurrencias de los objetos de la clase que se pueden dar en la asociación

Page 47: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación

Asociaciones calificadasCuando la multiplicidad de una asociación es

de uno a muchos, con frecuencia se presenta un reto muy particular: la búsqueda. Cuando un objeto de una clase tiene que seleccionar un objeto particular de otra clase para cumplir con el papel de la asociación, la primera clase utilizará un atributo en particular para localizar al objeto adecuado.

Factura Articulo1..n

listaArt iculoslistaArt iculos1..n

Page 48: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Asociación

Clases de asociaciónUna asociación, al igual que una clase, puede

contener atributos y operaciones. Cuando este es el caso se define una clase de asociación.

Page 49: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Agregación

Es una forma especializada de asociación, en la cual, el todo está relacionado con sus partes.

La agregación se conoce también como una relación “es parte de”.

Page 50: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Composición Una composición es un tipo especial de

agregación. Cada componente dentro de una composición

puede pertenecer tan sólo a un todo. Las partes se crean y destruyen con el todo. El todo es responsable de manejar la creación y

destrucción de las partes.

Page 51: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Composición

Frame

Button

Panel

TextArea

Page 52: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Realización

Una realización es una relación semántica entre clasificadores en la cual un clasificador especifica un contrato que el otro se obliga a cumplir.

Gráficamente una realización se representa como una línea punteada con una flecha cerrada grande apuntando al clasificador que especifica el contrato.

Page 53: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Realización

Contrato Empleado

Page 54: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Clases Abstractas

Una clase abstracta es aquella que no provee objetos y se utiliza por lo general como superclase para derivar clases que sí aportarán objetos al sistema.

Las clases abstractas se representan con el nombre de la clase en letra cursiva.

Page 55: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Interfaces

Son clases que definen un conjunto de operaciones accesibles externamente.

Se utilizan para modelar una colección de operaciones que definen un servicio que ofertan diferentes clases.

Las interfaces no contienen atributos, solo operaciones

Page 56: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Interfaces

Page 57: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Visibilidad Establece el tipo de acceso que van a tener las otras

clases a los atributos u operaciones de una clase. Existen tres niveles: Público: Todas las clases la pueden acceder. Se representa

antecediendo el símbolo de suma (+) al atributo o a la operación. Protegido: Sólo las clases heredadas lo pueden acceder. Se

representa con el símbolo de número (#). Privado: Sólo la clase original tiene acceso. Se representa con el

símbolo de resta (-). Todas las operaciones en las interfaces y realizaciones

son públicas.

Page 58: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Ejemplo de Diagrama de ClasesPersona

NombreDireccion

obtenDireccion()

Maestro

materiaCursadamateriacalificacion

registraCalificacion()

calif ica

Alumno

Kardex

0..n

1

1

tiene

1

1

0..n

Page 59: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Objetos

alumnoX : Alumno maestroY : Maestro

cursoZ : materiasCursadas

Page 60: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Objetos

Muestra un conjunto de objetos y sus relaciones en un punto en el tiempo.

Contienen:ObjetosEnlacesAl igual que los demás diagramas pueden

contener notas y restricciones.

Page 61: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagramas de Objetos

Se usan al igual que los diagramas de clases para modelar la vista estática del diseño, pero desde la perspectiva de una instancia real o de prototipo.

Modelar estructuras de objeto implica tomar un “snapshot” de los objetos del sistema en un momento dado.

Page 62: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Secuencia

: Alumno validador reporteKardex : Kardex

pantallaLogin

despliega

valida(alumno)

despliega(alumno)

Page 63: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Secuencia

Muestra las interacciones de los objetos ordenados en una secuencia de tiempo.

Muestra los objetos y las clases involucradas en el escenario y la secuencia de mensajes intercambiados entre los objetos necesaria para llevar a cabo la funcionalidad del escenario.

Page 64: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Secuencia

Page 65: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagramas de Secuencia

: Alumno validador reporteKardex : Kardex

pantallaLogin

despliega

valida(alumno)

despliega(alumno)

Page 66: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagramas de Colaboración

: Alumnovalidador

reporteKardex : Kardex

pantallaLogin1: despliega

2: valida(alumno)

3: despliega(alumno)

Page 67: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Colaboración

Muestra a los objetos con sus relaciones entre sí, además de los mensajes que se intercambian entre ellos.

Es semánticamente equivalente al diagrama de secuencia.

Page 68: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Colaboración

Page 69: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Colaboración

: Alumnovalidador

reporteKardex : Kardex

pantallaLogin1: despliega

2: valida(alumno)

3: despliega(alumno)

Page 70: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagramas de Estados

Page 71: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagramas de Estados

Un estado representa una condición en la vida de un objeto durante la cual se lleva a cabo una acción, se espera por un evento o se satisface una condicional.

El estado de un objeto puede ser caracterizado por el valor de uno o más atributos de su clase.

Los casos de uso y los escenarios sirven para describir el comportamiento del sistema, es decir, la interacción entre los objetos participantes.

Page 72: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Estados

Los diagramas de estado sirven para describir el comportamiento dentro de un objeto.

Muestra los estados de un objeto, los eventos o mensajes que causan la transición de un estado a otro y las acciones resultantes de ese cambio de estado.

Se crean sólo para los objetos con comportamiento dinámico significativo.

Page 73: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Estados

Page 74: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Transiciones de Estado

Representa un cambio de un estado origen a un estado sucesor, la transición puede estar acompañada de una acción.

Pueden ser: Automática

Se da al terminar la actividad que origina el estado. No-automática

Se da a causa de un evento. Los dos tipos son inmediatas y no se pueden

interrumpir.

Page 75: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Transiciones de Estado

Constan de cinco partes: Estado Origen: es el estado afectado por la transición Evento: El evento cuya recepción por parte del objeto

en el estado origen, hace posible el disparo de la transición si la condición de seguridad se cumple.

Condición de Seguridad: Expresión booleana que se evalúa cuando se recibe el evento, si es verdadera, la transición se dispara.

Page 76: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Transiciones de Estado

Acción: Operación atómica ejecutable que puede actuar directamente en el objeto dueño de la máquina de estado e indirectamente en otros objetos visibles por el objeto.

Estado Destino: El estado que está activo después de completarse la transición.

Page 77: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Detalles de los Estados

Page 78: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagramas de Estados

Page 79: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Componentes

Los diagramas de componentes muestran la organización y las dependencias entre componentes de software. Un componente puede ser: Un componente de código fuente

Por ejemplo un archivo con código en C. Un componente de ejecución (run time)

Por ejemplo un control tipo ActiveX. Un componente ejecutable

Un programa listo para ser invocado por el intérprete de comandos, por ejemplo un EXE.

Page 80: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Componente

Un componente de software es una parte física de un sistema que reside en la computadora (archivo, tabla de datos, ejecutable, etc.).

Un componente se puede visualizar como el mapeo de una o más clases del diseño en un pedazo de software.

Page 81: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Representación de Componentes en UML

Page 82: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Uso de interfaces entre componentes

Page 83: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

Diagrama de Distribución

Una vez definidos los componentes de software de un sistema, se requieren definir los componentes de hardware y la distribución de los mismos en el ambiente real de operación.

El elemento principal de un diagrama de distribución es el nodo : Nodo tipo procesador Nodo tipo dispositivo

Page 84: Ingeniería del Software Orientada a Objetosyaqui.mxl.uabc.mx/~molguin/as/IngSoft 6.pdf · Ingeniería del Software Orientado a Objetos Unidad 6: Vistas del UML. M.C. Martín Olguín

M.C. Martín Olguín (C) 2004

...Diagrama de Distribución